Monday, December 29, 2014

Solving 'Plugin org.apache.maven.plugin could not be found', or 'Could not find artifact in artifactory-release'

We recently purchased an Artifactory 3.4 pro license where I work, and I've been setting it up to work with Jenkins.

Unfortunately, Jenkins was failing when it was trying to download an Apache Maven dependency with a virtual repository I'd created.

Either I'd forgotten a step or it'd been already setup when I'd been playing with the evaluation version, but I'd failed to link a huge online maven 2 repository to my virtual repo.

[NOTE: I was also trying to update the .m2/settings.xml file and that wasn't working either in Jenkins. ]

If you're getting messages in your Jenkins console output like this :

[ERROR] Plugin [...] or one of its dependencies could not be resolved: Failed to read artifact descriptor for [...]: Could not find [...] in artifactory-release

and have setup your Jenkins job (AKA job) to work with Artifactory, this might be the issue.

Once I had my virtual repository serving artifacts from my local repository, I failed with adding a remote repository - and one of the most crucial : maven2.

In my case  org.apache.maven.plugins:maven-clean-plugin:2.5, wasn't found.

I added a new remote repository pointing to :

Then I went back to my virtual repo and added the Maven repo under Edit Virtual Repository > Basic Settings > Repositories.

I launched the build again and the error went away.

Friday, December 19, 2014

Running nmap scans to verify services aren't disrupted (e.g. elasticsearch)

I've worked in the software security space for about 5 years now, both in identity management and now SIEM/log analytics.

One useful UNIX command I never had experience with - until now - was nmap.

A big problem that we've encountered has been some services that work with elasticsearch were easily disrupted by external nmap scans.

To remedy this we had to reduce the number of externally accessible ports and also use nginx as a reverse proxy that would make people log into our web interfaces with a username and password.


There seem to be non-intrusive and more intrusive versions of nmap, to test what ports are open on a remote server and also more aggressive scanning and faster execution, respectively.

Some sample comands:

nmap -p 1-65535 [IP of server]
nmap -p [port range],[another individual port if needed] -T4 -A -v [IP of server]

These commands were definitely helpful when trying to verify the lock down of our ports; especially with some services like elasticsearch and cassandra. Additionally putting nginx in front of web browser services (e.g. elasticsearch HQ) that helped out even more.

nmap is certainly a nice tool for testing port lockdown.