views:

520

answers:

4

I've successfully created a small software engineering environment (SEE) for Java applications that is - amongst other tools - based on maven and nexus. My actual problem is - not a real surprise - that nexus usually requires access to the internet to to get the requested artifacts from the central repositories. But the SEE has to be strictly off-line and there's no way to change it (.. security reasons).

My first quick solution was to mirror the nexus/maven installation on machine, that was connected to the internet, run some standard pom's to populate the mirrored nexus and migrate the cache via CD-ROM to the target system. Pretty ugly. I'm not really looking forward to adapt that process to get updates for artifacts or new ones. In fact, we now usually just import the libraries we need and create new artifacts (with nexus) instead using the official ones from central and others.

Has anybody faced the same challenge and found a more clever and efficient approach?

Edit

Thanks for all the answers, I think I have to be more precise on the actual problem and the solution I'm thinking of at the moment: I think I have to create, populate and synchronise a private 'central' repository, based on central and other repos on the internet, or exactly: two identical repositories. One conneceted to the internet the other on the local network. Then I can keep the internet connected repository 'up-to-date' and copy the changes via DVD to the local repository - which is visible for Nexus.

Would it work? Is there documentation available on how to setup something like 'central' on a private server, is there a mechanism to synchronize selected artifacts?

(didn't want to post my thoughts at the beginning because I hoped to get totally different ideas)

+2  A: 

I've once worked in a network environment where a portion of a network wouldn't have access to the internet or any other net. Whenever we needed to update software within this network, we did the following:

  1. upload updated software to a "secure" host (step stone)
  2. disconnect step stone from net
  3. connect step stone to secure net
  4. push updated software to repository
  5. disconnect step stone from secure net

We fully automated this process by automatically configuring a switch to connect and disconnect networks appropriately (so there was a physical connection at all times but no usable IP connection). Maybe you could do something similar - it just depends on the flexibility of the definition of "disconnected" ;)

sfussenegger
You were lucky that you were allowed to allow 'step stone' to be connected to both networks - at least one after another. Unfortunatly my environment ist stricter... But it sounds like a nice approach!
Andreas_D
Well, it wasn't particularly nice - actually it was quite a beast with dozens of firewalls and different security policies. Not to mention all the security groups and certification that was required to get this into production use :)
sfussenegger
Sounds familiar to me ;-)
Andreas_D
Another approach we used in a similar environment was based on SSH tunneling - actually SSH tunneling was our swiss army knife :) We used several tunnels to get connections through different security tears, but basically it boils down to `ssh -R 8080:repo1.maven.org:80 secure.example.org update-repo.sh` update-repo.org would then download some files from localhost:8080 (i.e. from repo1.maven.org). It might require strict configuration of SSH daemons to get security approval tough.
sfussenegger
+3  A: 

I faced a similar issue in my environment.

Ordinarily our server hosting Nexus would not be able to access the Internet. However, I met with the operations team and explained to them that allowing Nexus to automatically download artifacts from the Internet is a huge productivity win for us.

Once they understood our needs, ops allowed the server to access a very strict whitelist of Internet IPs such as the central Maven repository. So we still have to go through ops to add new repositories or perform whitelist fixes when outside repository IP addresses change. But overall we felt it was the best compromise between security and productivity and it works for us.

See if your stakeholders will go for connecting your network to the Internet in a highly restricted whitelist-only manner once you reiterate to them how doing so will make you more productive and ultimately save everybody time.

Brian Laframboise
I like that idea - maybe I can convince my security guys of solution that combines whitelisting and temporary connection... although I still have doubts..
Andreas_D
Sure - combining a temporary connection with strict IP whitelisting sounds pretty powerful. If you script that, as per sfussenegger's answer, you should end up with something both secure and useful.
Brian Laframboise
+2  A: 

The Procurement features in Nexus Pro were designed exactly to handle this use case.

What is Procurement?

Procurement Suite User guide

Brian Fox
I'm not sure - doesn't it just shift the problem to another server? In my situation, I'll have to apply the same security constraints to the 'procured repository' server, iaw: no connection to the internet. So how do I populate und update the procured repository?
Andreas_D
It's meant to work in a scenario where Nexus can contact the remote repos, but the things being proxied are heavily controlled. By adding this extra "firewall" layer, organizations that previously had to be fully disconnected are now allowed to go only through Nexus.
Brian Fox
+2  A: 

Would it work? Is there documentation available on how to setup something like 'central' on a private server, is there a mechanism to synchronize selected artifacts?

Well, you could become a mirror of central but, what's the point of grabbing ~10 GB of artifacts? You won't need all of them and the usual recommendation is to use a repository manager.

Actually my initial thoughts was:

  1. Use a Nexus connected to the internet outside the SEE
  2. rsync the content of this Nexus to a DVD.
  3. Copy the content to the Nexus of the SEE via a DVD.
  4. Repeat periodically.

I found this solution ugly but, now that we have more details on your situation, it might be an acceptable.

Pascal Thivent
Thanks for your answer. Especially for the maven link, I think that helps a lot. The second nexus is a good idea, but I'd have to find a way to get artifacts into the nexus - nexus usually only caches artifacts on demand, like driven by a maven build, and there's 'no demand' on the outside. I think I'll tweak the 'public repository' solution - mirror the needed artifacts and create a clone of that server on the inner network...
Andreas_D
I didn't cover that part but this would indeed require to run maven on a pom with all required dependencies (for example using `mvn dependency:go-offline`, no need to compile anything). I guess using the pom(s) from the SEE is not an option...
Pascal Thivent