I'm playing around with the KIE Business Central Workbench deployed in an air gap environment using their latest docker image. My hope is to leverage it to give my customers the ability to manage our rules logic (implemented in .drl files) themselves. I started a docker container created from an image I built using the image they provide above. Here's my Dockerfile:
FROM quay.io/kiegroup/business-central-workbench:latest
COPY settings.xml /opt/jboss/.m2/settings.xml
USER root
RUN chown jboss:jboss /opt/jboss/.m2/settings.xml
USER jboss
The settings.xml listed above contains a mirror to our locally hosted nexus repository. I added this due to requests in the logs going to maven central which always failed. I then exec'ed into the container and added a user with the admin role, then hit http://localhost:8080/business-central per the second link above. I then added a space, then a project with the space, then attempted to create new assets within the project. Adding any kind of asset yielded the following error:
Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.default:artifact:jar:1.0.0
at deployment.business-central.war//org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282)
at deployment.business-central.war//org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:198)
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:202)
... 101 more
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.default:artifact:pom:1.0.0 from/to (https://my.nexus.org/): Connection reset
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
at deployment.business-central.war//org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:267)
... 103 more
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.default:artifact:pom:1.0.0 from/to (https://my.nexus.org/): Connection reset
at deployment.business-central.war//org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:43)
at deployment.business-central.war//org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
at deployment.business-central.war//org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at deployment.business-central.war//org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
at deployment.business-central.war//org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
at deployment.business-central.war//org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
... 106 more
The name of this dependency (as well as its distinct absence of any artifact by that name here) makes me think this is some kind of KIE artifact which gets created on the fly. The only config change I made was to add the admin user via exec'ing into the container. I'm scratching my head as to why this doesn't seem to work out of the box. Any ideas?
Related
I'm having issues when I build my project using Maven and it attempts to download an artifact from my privately hosted Artifactory repository. I have a large number of artifacts used by my project that are stored in this Artifactory instance. It downloads many of them fine during the build process, but when it gets to the org.apache.solr SOLRJ artifact download, it fails with a "401 Unauthorized" error.
I know my configurations in my Maven project POM file and my local Maven settings file are correct (repo ID matches, username and password entered, etc.) because it successfully downloads the first half of the artifacts referenced in my project and only fails when it gets to the SOLRJ artifact. In addition, when I navigate to the repo in a browser window, I can freely navigate the tree and view other artifacts without providing credentials, but when I try to click on the link for the org.apache.solr folder, it prompts me for credentials and none of my known credentials work, even though I know the username and password are correct. So it seems the issue is isolated to this one artifact.
I have copied the org.apache.solr contents from another local repository to attempt to get it to skip downloading the file, but it is still trying to download even though it would appear the version is correct and matches.
I am confused why, when navigating the repo in the browser, this one folder in the repo would be prompting for authentication when no other artifacts are behaving the same way, and why none of my username/passwords entered (including the administrator username/password) are being recognized and accepted.
Any help is greatly appreciated to either a) point me in the right direction to make that artifact behave like the others and not require a username/password, or b) get my build to recognize that I've already got the files in the local repository so it doesn't need to download them again.
Relevant setup information: gradle 4+, relatively new installation of Artifactory (Pro 6+), artifactory gradle plugin version 4+
When attempting to run the build command on a local development environment in both Eclipse Photon and IntelliJ (late 2017 version), I run into dozens and dozens of 403 errors when making a HEAD request for dependencies. But, if I login to Artifactory through a web browser as the user that gradle is using and go to the exact same URL, it has no problem reaching the resource that gradle failed to reach. The problem occurs with every user on Artifactory, even one with admin privileges. The jars I'm looking for are part of a virtual repository with dependencies both internal to the artifactory installation and external. Finally, the build used to work just fine a month ago, and nothing I can think of has changed to permissions.
tl;dr only when logging in from gradle and using Artifactory plugin, a virtual Artifactory repo returns 403 errors on nearly every dependency for every user
This question: Docker pull from artifactory fails with credentials issue seemed close, but is using docker+jenkins (I'm not) and has no answers.
When I finally dug into the system logs, I found many lines like this one: "Rejected artifact download request: User XYZ is not permitted to deploy 'SOME JAR' into 'SOME CACHE JAR'"
It appears that users must have DEPLOY permissions in order to download an artifact that will be cached (behavior of virtuals/remotes.) This may also explain why the build used to work - the cached jars wouldn't have needed updates a month ago when I'd just added the remote and downloaded everything.
Adding deploy permissions to my user for the relevant repositories fixed the issue.
I have a nexus3 oss (3.13.0) docker container deployed in aws backed with a s3 blobstore. Our ci jobs are continuously uploading artifacts to this repo and worked just fine. However, off late uploading maven artifacts takes a long time and in some cases eventually fails.
It was originally version 3.12.0 and thought upgrading version might help, but it didn't. Also checked if it has anything to do with connectivity or permissions to s3 and found nothing.
Update:
Switched to a file based blobstore and the issue still persists, so we can at least rule out that it's not specific to s3 blobstore.
The repo size is greater than 20GB so increased the heap allocation as recommended in the documentation, but still did not help.
Any idea what might be happening?
Here's what I see in the logs on nexus3:
org.sonatype.nexus.blobstore.api.BlobStoreException: BlobId: null, Error uploading blob
at org.sonatype.nexus.blobstore.s3.internal.MultipartUploader.upload(MultipartUploader.java:98)
at org.sonatype.nexus.blobstore.s3.internal.S3BlobStore.lambda$0(S3BlobStore.java:220)
at org.sonatype.nexus.blobstore.s3.internal.S3BlobStore.create(S3BlobStore.java:257)
at org.sonatype.nexus.blobstore.s3.internal.S3BlobStore.create(S3BlobStore.java:217)
...
Caused by: org.eclipse.jetty.io.EofException: Early EOF
at org.eclipse.jetty.server.HttpInput$3.getError(HttpInput.java:1138)
... 122 common frames omitted
The solution was to set the right order of realms in the admin section. In my case the ldap realm was ordered before the local authentication and local authorizing realms, but users were actually connecting using a locally created user. So it would try to do a ldap lookup before a local lookup which was causing the delay in the authentication mechanism. Once the order was changed to move the local realms above the ldap realm, things got better and uploads were much faster.
I have an instance of Artifactory installed locally. Within the instance, I am able to create references to other remote repositories.
Now, I have another instance of Artifactory, which exposes its own repository: .../remoteArtifactory/repo
I am trying to point to this repo in the first instance of Artifactory.
But in doing so, I have:
Connection failed with exception: Circular redirect to
".../remoteArtifactory/repo"
What am I doing wrong here?
I had exactly the same problem as you, and fixed it by completely ignoring that error message and saving the repository. To reiterate:
Ensure you have the correct path to the remote repository, eg: http://host:8080/artifactory/libs-release-local/
Click Test, and you'll get the Connection failed with exception: Circular redirect to - Ignore this!
Click Save
Note: different versions of Artifactory have slightly different paths/URLs. This caused me a little grief.
Remote Repository Settings
I guess it's worth mentioning that I needed to specify the local proxy server (TdmsProxy).
Also, to confirm that you've got the correct path to the remote instance, check that you can receive a POM via the browser (or wget) from it, eg:
http://your-remote-repo:8080/artifactory/libs-releases-local/com/company/area/project/version/project-version.pom
Once, you've received the POM, just use the first part of the URL, eg:
http://your-remote-repo:8080/artifactory/libs-releases-local/
(I realise you've probably checked your path at least 10 times, but this bit me!)
I have problems with configurations using Maven + Artifactory.
I try to download a new external file using a user created in Artifactory and my Artifactory doesn´t make download, claiming "Access denied" but if I put the same credentials as defined in remote settings, my application can download every external jars.
If I use the same permission setting of my remote configuration settings.xml where the Artifactory was installed (user admin) I can make downloads quickly.
There´s some way to configure to create a user in my Artifactory and configure the permission to make downloads of new artefacts? Because I didn´t find in anywhere.
I think that is more secure for my company if I have the possibility to create a new user in my Artifactory and just give the permissions: read and to download new artefacts but this option doesn´t exist in Artifactory.
How could I do this?
Because you've created a user entity within Artifactory, make sure it's got at least read permissions on all the repositories you'd like to resolve from.
For easier Maven configuration, you can also use Artifactory to generate proper Maven settings for yourself; this helps to reduce typos and reference mistakes (make sure you're logged in as the user entity you've created whilst generating the settings). After applying the settings file you can also run the mvn help:effective-settings goal on your project to make sure everything was applied correctly.
Finally, if you're required to authenticate with the remote repository you're proxying, you'll need to he specify the credentials in the configuration of that remote repository.
Make sure the user you are using to connect to Artifactory has Deploy permissions in Artifactory. The Deploy permission allows the user to download artifacts from repositories (in other words, populate cache with remote artifacts).
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions
Deploy Allows deploying artifacts and deploying to caches (i.e.
populating caches with remote artifacts)
More information from the JFrog forum:
http://forums.jfrog.org/Maven-using-anonymous-user-even-though-artifactory-server-setup-in-the-settings-xml-td4634521.html