We are evaluating JFrog Container Registry. We already use Artifactory Pro. For evaluation, we used a vanilla installation from a ZIP on Linux that used the service install script and installation using apt-get. Both have the same LDAP problem. When configuring LDAP and saving the configuration, we get no class def found errors.
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.springframework.security.ldap.DefaultSpringSecurityContextSource
at org.artifactory.security.ldap.ArtifactoryLdapAuthenticator.createSecurityContext(ArtifactoryLdapAuthenticator.java:82)
at org.artifactory.security.ldap.ArtifactoryLdapAuthenticator.createBindAuthenticators(ArtifactoryLdapAuthenticator.java:197)
at org.artifactory.security.ldap.ArtifactoryLdapAuthenticator.init(ArtifactoryLdapAuthenticator.java:162)
at org.artifactory.security.ldap.ArtifactoryLdapAuthenticator.reload(ArtifactoryLdapAuthenticator.java:180)
This seems really weird because LDAP works fine with our Artifactory and JCR looks like it is just a stripped down version of Artifactory or Artifactory configured to only be used as an image registry. Is anyone else experiencing teething problems with JCR? It makes me think JCR is not ready for prime time
LDAP is supported in JFrog Container Registry the same way it is supported with JFrog Artifactory Pro. I have just configured LDAP on JCR with no problem actually. Can you please add the entire stack trace so we can have a further look?
You can also open a Jira ticket here: https://www.jfrog.com/jira or contact JFrog Support directly (support#jfrog.com) to get support with setting up LDAP.
Related
On my windows server 2022, I recently installed Teamcity Professional 2022.10 (build 116751) using the windows installer, and once I got it up and running I an agent through 'Install Agent' in the GUI, again using the windows installer.
I then created my first project, which I managed to do a successful build for, also running my tests. The next step was creating a docker image from this build, and pushing it to my repository. Here however, I am facing issues: my installed agent is not compatible for that build, giving me the following incompatibility error:
Incompatible runner: Docker
Unmet requirements:
docker.version exists
docker.server.version exists
While it's clear to me that something is going wrong with the docker version, I'm not sure what exactly, or how/where to fix it. Since both the agent and the teamcity installation are running as windows services (Windows server 2022), I'm not sure if the docker version has to be installed in something running in the agent service, or simply on my windows server installation. The latter is the case: running docker info shows that it is installed.
I have tried to somehow connect to my agent, to try and install docker there, using its hostname through RDP, which does promt me for a username and password, but I have no idea which combination to use there. I have tried using the credentials of my account running the process, but none of the credentials seem to work. Nowhere in the installer did I have to pick any credentials, so I am not sure how to connect to the agent at all, or if I even can/must connect to it to install docker on it.
I found also some logging on the agent:
[2022-11-05 17:07:49,729] INFO - rains.buildServer.AGENT.DOCKER - Failed to parse version: Docker version master-dockerproject-2022-03-26, build dd7397342a
[2022-11-05 17:07:49,729] INFO - rains.buildServer.AGENT.DOCKER - Docker client is not available. Check whether it has been installed and PATH environment variable contains path to it.
[2022-11-05 17:07:49,777] INFO - Server.powershell.agent.DETECT - Found through registry: PowerShell Desktop Edition v5.1.20348.1 64-bit(C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)
[2022-11-05 17:07:49,778] INFO - Server.powershell.agent.DETECT - Detecting PowerShell using CommandLinePowerShellDetector
[2022-11-05 17:07:50,125] INFO - rains.buildServer.AGENT.DOCKER - Docker-compose is not available. Check whether it has been installed and PATH environment variable contains path to it.
In the parameters of my agent I can find the path parameter, which includes 'C:\Program Files\Docker;' which makes me think it is indeed the docker installation of my windows server that matters, but I then fail to see what is going wrong exactly.
Since the agent was installed as a service, it uses the docker version of my windows server installation. I wanted to do a reinstall of docker to see what was going wrong, and I noticed that I couldn't uninstall it through for example control panel, windows seemed to have no idea that it was installed, even though docker info would specify both a client and a server that were running.
After hunting down all the 'hidden' docker files of the installation and reinstalling it on the host machine, these warnings went away.
I'm still not sure if it's possible to connect to the build agent though, but since it seems to use the resources on the host machine, that seems to not be necessary anyhow.
I can only reproduce this error on my Mac Air. I have a Mac tower from 2010 that I've opencore'd to 12+ and it does not have this issue.
For the life of me, I cannot get through this error with the #matterlabs/hardhat-zksync-solc plugin. As you can see in the window behind my CLI, I am connected to docker hub through Docker Desktop. I can also log into docker via the CLI using docker login. I've already tried logging in and out using various methods.
My last suspicion is that maybe a port is natively blocked? Where would I begin trying to troubleshoot this?
Just answering this to mention that support for Docker has been deprecated and it's recommended that users use binary as compiler source to compile contracts with zksolc.
You can find more info on how to compile contracts on zkSync here: https://v2-docs.zksync.io/dev/developer-guides/contracts/contracts.html
And specific information about the zksolc harhdat plugin here: https://v2-docs.zksync.io/api/hardhat/plugins.html#hardhat-zksync-solc
Jenkins Controller reports : Unable to create live FilePath for i-xxxxxxxxxxxxx and Agent is marked Offline
Googling this error indicates that it is a problem with the communication paths between Controller and Agent, but what?
Background:
Jenkins Controller running v2.332.1, Java 11 64bit OS, inside a docker container
Jenkins Agents running Swarm-Client jar downloaded from the Controller on startup. Swarm Plugin Version 3.32 Java 11 and 64bit OS, inside a docker container
Agents and Controller are hosted on separate EC2 instances in AWS with Security Group permissions on the relevant ports.
The Instance starts up runs the Cloud-Init, downloads the swarm-client.jar from Jenkins Controller and then runs it with the parameters required to connect to the controller. I mention this to avoid the "are you using the correct version" comments :-)
The Agent connects and is all fully online and gets busy servicing the pending Job queue.
Then some time later, indeterminate, some jobs last > 24 hours and have not failed, other jobs last minutes and sometimes fail.
Things I have tried: (some)
The Swarm Client jar can use either WebSockets and connect to the FQDN of the Jenkins controller or use the JNLP protocol to connect to the IP and dedicated agent connection port (fixed value on the Controller).
Similar behavior is seen with either protocols.
Opening all the AWS Security Groups: incase there was another port, not mentioned, that needed to be open.
Bypass AWS Load balancer: Agent connects directly to Controller IP:PORT via JNLP
Matching Versions: Swarm Client downloaded from Controller
Updated Versions: Jenkins 2.319.3, 2.332.1
Normalized Java environments: Java 11 64bit OS
Enabled Logging on the Agents: periodic communications happens and then stops after a while, without obvious reason.
Increased Controller Instance size: m5.xlarge -> m5.2xlarge
Bumping Jenkins up to a non-LTS version allowed the connections to become more stable.
Jenkins 2.341 and Swarm-Client version 3.32 both use Remoting version 4.13
Now, while I am not particularly happy about running a non-LTS version of Jenkins, I am pleased to have found a workaround
I have also struggled with this issue, I am adding details here, so, that others don't have to struggle.
This is all what i tried:
we had everything running when we had JDK 8 in both master and slave.
So, we added code to have JDK 11 in both and I replaced ec2 of Jenkins with a new one with help of ASG.
So, issue came, and we reverted, but still the issue was the same.
So, I was just assuming by this warning in jenkins as it says moveto jdk 11,as there anything like deprecated...so, I was just checking also we can try this new version of Jenkins as well, what they have mentioned. --going to Jenkins 2.344 with jdk8 ,same issue, and also to different jenkins version didn't help and I lost hope.
I have tried with a biggest ec2 type for slave --didn't help
I checked htop in slave --didn't help.
I tried restarting jenkins master --didn't help.
I tried changing remote dir for slave as mentioned in stack overflow --didn't help.
So, I have a thought, as Jenkins ec2 is terminated and new ec2 came up, so, things may get updated in jenkins by that...and also warning showing to have a new version of jenkins and jdk 11..so, that looked somewhat a hope to me.
I tried by increasing tomeout 20 min in slave setup, didn't help.
I tried adding this command :sudo yum -y update --security in init script of node of jenkins ec2 plgin--will not help.
we have tried jdk 11 image, jdk8 image and new jdk8 jenkins version image, issue was same in all.
So, what finally solved the issue:
that we moved to older version of jenkins:
https://hub.docker.com/layers/jenkins/jenkins/jenkins/2.330-jdk8/images/sha256-97fcb[…]17da34f0d07c021ab57083ee8c77dc4b21281d3498137?context=explore
Fixed by upgrading to Jenkins 2.344
I'm running the Jenkins as a Docker container on a Virtual Machine on Google Cloud Platform. On the very first screen of setup, I can see that a lot of plugins did not install in my Jenkins server?
Please let me know how to resolve this issue? Is it something due to with the security on the cloud by default which restricts downloading of plugins?
Refer following link for screenshot:-
https://storage.googleapis.com/mydockerissues/Jenkins%20Plugins%20Issue.PNG
Cheers
Something similar happened to me when running Jenkins on Docker on my local machine. To get everything to install I had to keep retrying. It took several retries but eventually I got everything installed.
I'm not sure why this is the case. Maybe it fails downloads whose dependencies aren't installed yet?
I'm currently trying to use IntelliJ to deploy to a local GlassFish instance running in Docker on my Windows 10 box.
I'm following the instructions here on deployment, using the remote server setup.
However, when calling the run command, I get the following error from IntelliJ:
Artifact my-project:war: java.io.IOException: com.sun.enterprise.admin.remote.RemoteFailureException: File not found : /opt/glassfish4/glassfish/domains/my-domain/config/C:[PATH_TO_MY_TARGET_DIR]\my-project.war
It seems like it's trying to pass too much of the path when uploading.
Interestingly, I tried this same setup (different IP addy) deploying to a GlassFish instance running in Docker in a local Ubuntu VM, and it has no problem.
Anyone gone down this road?
I have the same problem and contacted JetBrains.
It seems to be a bug in IntelliJ wich will be hopefully fixed quite soon. Here is the link for reference https://youtrack.jetbrains.com/issue/IDEA-180292.