Next Level (Step 2: Renewal á la Cron)

Seit Dezember ist nun ganz offiziell die Public Beta von Let’s Encrypt verfügbar. Die ersten Zertifikate laufen nun innerhalb der nächsten 2 Wochen aus, also auch bei mir (ich hatte ja auch Ende November bereits alles auf SSL-only umgestellt).

Mit einem Blick in den Kalender wurde es daher auch mal zeitig, den automatischen Renewalprozess ans Laufen zu kriegen, denn die Zertifikate sind ja bekanntlich immer nur 90 Tage gültig. Manuelles Eingreifen als Dauerlösung scheidet aus. Ich bin ja Entwickler, da ist jede Wiederholung eines Arbeitsschrittes schon eine zu viel.

Das Szenario

Ein Multi-Site-Konfiguration verschiedener Domains für einen Nginx, jede Domain hat ihre eigenes Zertifikat und Private Key. Diese Paare müssen jeweils validiert und ggf. erneuert werden.

Für den initialen Einrichtung hatte ich auch den offiziellen Client verwendet. Aber erstens ist dieser zu mächtig mit vielen Abhängigkeiten, denn ich will nur (neue) Zertifikate und keine Modifizierung irgendwelcher Konfigurationsdateien. Das Zweite wiegt noch schwerer: Dieser funktioniert (aktuell) nur als root vernünftig, was unter anderem auch daran liegt, dass er kurzfristig Port 80 nutzen muss. Das ist aber natürlich mit einem laufenden Webserver „unhandlich“.

Aber es gibt Alternativen: Und mal gar nicht so wenige. Prinzipiell sind Ideen wie der Caddy Server (ein „Webserver“ mit eingebautem ACME-Client) interessant, aber nicht für diese Situation angebracht. Ein ander Mal vielleicht…

Exkurs: Der gesamte Prozess der Verifizierung der Domain geschieht über das Protokoll „Automated Certificate Management Environment“ oder kurz ACME. Das wurde ursprünglich von Let’s Encrypt entwickelt und aktuell ist es als IETF Protokoll im Gespräch. Das Protokoll beschreibt, wie Clients (bspw. für Webserver) ein Zertifikat anfragen und bestätigen können. Daher kann prinzipiell jeder einen solchen Client (und natürlich auch Server!) bauen; fertige Plugins „out-of-the-box“ für Webserver sind also auch bald möglich — Caddy macht es sogar schon vor.

Meine Wahl fällt auf letsencrypt.sh von Lukas Schauer: ein kleines und überschaubares Bashscript, welches sich ebenfalls einfach konfigurieren lässt. Da ich ja bereits „Bestandsdaten“ hatte, wollte ich natürlich gerne die vorhandenen Zertifikate und Schlüssel „importieren“. Netterweise hat Lukas dafür schon etwas vorbereitet. 😎

Schritt-für-Schritt vom Import bis zur Cron:

  • Annahme: www-data ist die Gruppe des Webserver-Users.
  1. Wir legen einen neuen dedizierten UNIX-Account an, nennen wir ihn doch bill (Name d. Red. bekannt). Denn Bill is smart!
    1. Nicht vergessen: bill darf sich nicht einloggen können; am Besten kein Passwort und keinen Public Key hinterlegen.
    2. bill wird Mitglied der Gruppe www-data (als Default-Gruppe): usermod -g www-data bill
  2. Das Git-Repository klonen wir uns einfach in sein Home-Verzeichnis: git clone https://github.com/lukas2511/letsencrypt.sh.git
    1. In das Verzeichnis wechseln.
    2. Testweise ./letsencrypt.sh -e starten. Sollte kein Fehler kommen, erstmal alles gut. Ansonsten dafür sorgen, dass openssl und curl installiert sind.
  3. Wir legen das Verzeichnis /etc/letsencrypt.sh an und passen die Rechte so an, dass nur Mitglieder der Gruppe www-data dort lesen und bill zusätzlich schreiben darf: chown bill:www-data /etc/letsencrypt.sh && chmod 750 /etc/letsencrypt.sh
  4. Vorbereitungen
    1. In bill wechseln… su – bill
    2. … und in das eben erstellte Verzeichnis /etc/letsencrypt.sh wechseln.
    3. Eine leere domains.txt erstellen (siehe domains.txt.example)
    4. Jeweils die config.sh.example und hooks.sh.example aus dem Repository kopieren und ablegen, dabei den Suffix .example entfernen.
    5. In der nun frischen config.sh das BASE_DIR setzen: BASEDIR=/etc/letsencrypt.sh
    6. Einen symbolischen Link auf /var/www/letsencrypt erstellen: ln -s /etc/letsencrypt.sh/.acme-challenges /var/www/letsencrypt
    7. Das eben erwähnte Linkziel anlegen: mkdir /var/www/letsencrypt
    8. Aus Sicherheitsgründen sollten die Dateien und Verzeichnisse nur für bill zu schreiben sein.
  5. Letsencrypt.sh-Konfiguration
    1. Falls schon mit Hilfe des offiziellen Client Zertifikate installiert wurden:
      1. Mit dem Importscript (siehe hier) werden alle Zertifikate ermittelt und sauber in /etc/letsencrypt.sh/certs/$DOMAIN geschrieben.
      2. Einen eventuell vorhandenen Account Key kann man mit dem zweiten Importscript auch ermitteln; falls vorhanden einfach unter /etc/letsencrypt.sh/private_key.pem ablegen.
    2. Falls noch keine Zertifikate angelegt wurden, dann muss man die Datei domains.txt selber editieren — oder auch nachträglich korrigieren.
  6. Nginx-Konfiguration
    1. In Punkt 4 wurde bereits das Verzeichnis /var/www/letsencrypt für die Response-Challenges angelegt. Da das Protokoll vorsieht, das der Webserver unter Port 80 (!) und dem Pfad /.well-known/acme-challenge die Antworten liefern kann, muss jeweils bei jeder Seite eine kleine Ergänzung eingefügt werden. Relativ am Anfang innerhalb der HTTP-Direktive sollte daher ein Verweis auf eben genanntes Verzeichnis stehen. Im Folgenden ein Beispiel zusammen mit HTTPS-Always: .
      Es muss sicher gestellt werden, dass für alle(!) Domains (inkl. Subdomains) das Verzeichnis über HTTP erreichbar ist. Am Besten eine Datei mit „Hello World“ ablegen und die Erreichbarkeit versuchen. Idealerweise mit curl, denn der Browser forciert u.U. die HTTPS-Erreichbarkeit (etwa durch HSTS oder Plugins).
    2. Und schließlich muss der Pfad zum Zertifikat und zum Schlüssel umgebogen werden.
      1. Entweder: In der Nginx-Site-Konfiguration wird auf den neuen Pfad gezeigt: /etc/letsencrypt.sh/certs/$DOMAIN/fullchain.pem und ~privkey.pem
      2. Oder: Man kopiert sich die Dateien im Hook (siehe unten).
  7. Hooks
    1. Letsencrypt.sh bietet aktuell drei Hooks an, davon ist interessant: deploy_cert (nachdem ein neues Zertifikat erstellt wurde)
      1. Falls man das Zertifikat erst noch an die richtige Stelle kopieren will (als bill).
      2. Es bietet sich an, den Webserver neu zu starten: sudo service nginx reload
  8. Cron finally
    1. Anschließend runden wir das Ganze noch ab: Wir richten eine wöchentliche Cron auf, der letsencrypt.sh aufruft und die Renewals automatisch anwirft. Beispiel: 0 0 * * Sat (cd /home/bill/letsencrypt.sh; ./letsencrypt.sh -c > /home/bill/last_renew_check.log) für einen wöchentlichen Check am Samstag.

Zusammenfassung

Mit der Anleitung haben wir nun einen wöchentlichen Cronjob, der jeweils prüft, ob die konfigurierten Domains ein Zertifikat haben und ob dieses noch gültig ist. Dabei wird bereits im Voraus ein neues generiert. Die Verifikation geschieht ganz regulär über ACME, der Webserver liefert die entsprechenden Daten im laufenden Betrieb.

letsencrypt.sh liegt im Homeverzeichnis eines dedizierten Benutzers ($HOME/letsencrypt.sh), die Konfiguration unter /etc/letsencrypt.sh.

Die Zertifikate und Schlüssel liegen in /etc/letsencrypt.sh/certs (BASE_DIR).

Alle Pfade lassen sich natürlich ändern, dafür einfach in der Dokumentation nachschauen.

Anmerkungen

  • Man kann auch ein anderes BASE_DIR (anstatt /etc/letsencrypt.sh verwenden; die config.sh muss  weiterhin unter /etc/letsencrypt.sh (oder lokal) vorhanden sein.
  • bill is smart und darf deswegen natürlich keinen Service einfach neu starten. Das lässt sich mit sudoers lösen: bill ALL = NOPASSWD: /usr/sbin/service nginx *

OS X 10.11 El Capitan, RVM und MacPorts

Dieser Artikel dient nur als Bestätigung von meiner Anleitung OS X 10.10 Yosemite, RVM und MacPorts/HomeBrew für das neue OS X 10.11 El Capitan.

Mehr oder weniger stimmt die Anleitung auch für El Capitan. Anmerkungen habe ich dabei (Stand 17. September 2015) nur folgende:

  • Basis:
    • OS X 10.11 El Capitan GM
    • Xcode 7 GM
    • sudo xcode-select –install
  • Die MacPorts gibt es noch nicht als Binary für 10.11; daher muss man sich das selber kompilieren, was aber kein großes Problem ist. Ich bin dieser Anleitung gefolgt, wobei man natürlich manche Schritte nicht als sudo machen müsste. Die saubere PATH habe ich aber befolgt. (Update 04.10.15: MacPorts ist in einer neuen Version veröffentlicht worden.)
  • gpg habe ich mittels sudo port install gnupg installiert. Hat seltsamerweise zwei Anläufe gebraucht, vielleicht war es auch nur ein Verbindungsproblem.
  • RVM hat wohl die Skripte mittlerweile angepasst und stolpert nicht mehr über das fehlende apple-gcc42
  • RVM dann wie gehabt installieren. Seltsamerweise war bei mir automatisch homebrew aktiv (obwohl MacPorts verfügbar sind); lässt sich bekanntlich aber mit rvm autolibs macports lösen. (Update 04.10.15: Das Problem hatte ich auf einem anderen System nicht mehr.)

OS X 10.10 Yosemite, RVM und MacPorts/HomeBrew

Nach dem Update auf Yosemite funktionieren die bisher installierten Rubies via RVM nicht mehr, und man muss diese neu installieren. Schlimmer noch, das dies aber nicht so ohne weiteres geht.

Legen wir los.

1. Aktuelles Xcode

Nach der Installation sollte man das aktuelle Xcode 6.1 installieren. Das ist aktuell noch nicht via MAS (Mac App Store) verfügbar, liegt aber im Apple Developer Center zur Verfügung.

Angeblich reichen mittlerweile auch die Command Line Utils, das habe ich nicht ausprobiert. (Xcode bietet ja auch den iOS Simulator, daher ganz praktisch…)

Gegebenenfalls muss man den MAS nochmals aufsuchen und die Updates prüfen. Bei mir erschienen da Folge-Updates für Xcode; die hießen zwar Command Line Utils, waren es aber scheinbar nicht?!

2. Command Line Utils

In dem Terminal kann man mit xcode-select –install dafür sorgen, dass die Verfügbarkeit der Command Line Utils gewährleistet ist. Falls nicht, dann den kommenden Dialog bejahen und warten.

3.1 MacPorts

Falls die MacPorts vor dem Update installiert waren, dann muss man eine Migration durchführen (einfach port ausführen, dann erhält man den Hinweis). Falls man nicht unbedingt die alten Ports braucht (man installiert sich die notwendigen dann eh neu), dann kann man auch einfach alle weg schmeißen: (a) Einfach die neuen MacPorts via macports.org runterladen und neu installieren, dann (b) alle deinstallieren mit sudo port -f uninstall installed und anschließend (c) alles Informationen löschen sudo port clean all ausführen. Die letzten beiden Schritte dauern ein paar Minuten.

3.2 HomeBrew

Falls HomeBrew installiert war, dann hier schauen, aber das sollte man sich überlegen. Ich würde da im Zweifel auch eher einen Kahlschlag machen. Man hat da eh meistens in der Vergangenheit Dinge installiert, die man gar nicht mehr braucht.

4 RVM

Wir brauchen auf jeden Fall die neuste Version: rvm get stable

Bei mir hat RVM bei einem Upgrade die Autolibs (also den zu verwendenen Default Package Manager) von MacPorts zu HomeBrew gewechselt, daher muss man ggf. rvm autolibs macports ausführen. (Hinweis: Das gilt ab sofort, das heißt bereits offene Shells laufen noch mit der alten Einstellung!)

Da bereits Rubies und Gemsets vorhanden sein werden, sollte man diese alle entfernen (sie linken teilweise auf nicht mehr korrekte Ports/Brews): rvm remove all

Auch löschen wir alle lokalen Informationen: rvm cleanup all

4.1 RVM und apple-gcc42

Sowohl die Variante über MacPorts als auch HomeBrew stolpern aktuell bei der Installation von älteren Rubyversionen über den Compiler apple-gcc42. Beide wollen diesen installieren, aber das funktioniert nicht (mehr?) unter OS X 10.10 / Darwin 14.

Allerdings braucht das Kompilieren von Ruby nicht zwangsläufig GCC, sondern läuft auch mit clang: rvm install 1.9.3 –with-gcc=clang läuft wunderbar — sowohl unter MacPorts als auch HomeBrew. Beim aktuellen Ruby 2.1.3 ist das nicht mehr notwendig.

5. RVM Autoinstall

Unter Berücksichtigung von Projekten mit alten Rubies (siehe Schritt 4.1), funktioniert jetzt die automatische Installation von Ruby, Gemset und deren Path-Aktivierung auch für Gemfile. Die ~/.rvmrc benötigt dafür ja nur:

rvm_install_on_use_flag=1
rvm_autoinstall_bundler_flag=1
rvm_gemset_create_on_use_flag=1

OS X und Fusion Drive auf Macs älter als Late 2012 (Update 02.12.2012)

Update 25.11.2012: Siehe unten!

Update 02.12.2012: Mit Videos!

Als Ende Oktober diesen Jahres Phil Schiller von Apple die neuen Macs vorstellte, ließ er auch ein paar wenige Worte im üblichen Awesom-Wirrwarr über „Fusion Drive“ fallen. Dabei handelt es sich um eine Kombination von SSD und HD, um die Vor- und Nachteile beider Techniken effizient auszunutzen: Geschwindigkeit aber wenig Speicher bei der SSD, viel Speicher aber langsamer bei der üblichen HD.

„OS X und Fusion Drive auf Macs älter als Late 2012 (Update 02.12.2012)“ weiterlesen

jQuery AutoSuggest v2 (pre) – oder: Heißer Scheiß mit grunt, coffee, sass, github und travis

In einer bislang nur als Pre-Release verfügbaren Version 2 gibt es nun von mir das jQuery Plugin AutoSuggest auf GitHub. Das Plugin basiert weitestgehend auf der Version von Wu Yuntao, welcher aber die aktuell verfügbare Version 1.6 nicht mehr wirklich zu pflegen scheint. Ursprünglich wurde das Plugin 2009 von Drew Wilson entwickelt. Das dortige Plugin dort wurde das letzte mal im März 2010 in der Version 1.4 veröffentlicht.

„jQuery AutoSuggest v2 (pre) – oder: Heißer Scheiß mit grunt, coffee, sass, github und travis“ weiterlesen

Herrlicher PHP-Rant

Da hat jemand einen äußerst umfangreichen PHP-Rant verfasst.

PHP: a fractal of bad design

Falls ein Leser also mit PHP arbeitet: Lesen! Und zwar nicht unbedingt deswegen, um nachher PHP abzuschwören (okay, das wäre aber auch keine schlechte Idee), sondern um die Stolpersteine besser zu wissen und in Zukunft besser zu umfahren.

Der Autor lässt hierbei wirklich nichts grade stehen und geht alles an: von Parser über die Exceptions bis hin zur Security. Es schadet übrigens natürlich nicht, diesen Beitrag dan auch selbst kritisch zu lesen (nicht alles, was PHP seiner Meinung nach schlecht/nicht kann, ist auch wirklich so schlimm), aber es sollte mindestens sensibel machen.

Und nebenbei kann man über so manches „Was haben sich die PHP-Entwickler dabei nur gedacht?“ entweder laut lachen oder weinen — je nach dem.

Eine Jar (OJDBC) nachträglich in die Ziel-Jar integrieren

Für das visualDependencies-Projekt stand ich eben vor dem Problem, dass zur Laufzeit ein Oracle-JDBC-Treiber benötigt wird. Leider kann man ihn jedoch nicht als Abhängigkeit konfigurieren, da zum einen das Projekt unter der GPL läuft, und zum anderen es überhaupt keinen offiziellen Weg dafür gibt. Für den eigenen Buildprozess kann man selbstverständlich ein lokales Repository nutzen, das Artefakt lokal deployen bzw. den Buildserver entsprechend konfigurieren.

Da jedoch das Projekt im Form des Sourcecodes „für alle“ erreichbar sein soll, fallen diese Optionen zumindest für diese Situationen weg. Es muss also eine Möglichkeit geben, den OJDBC-Treiber nachträglich in das fertige Applikations-Jar zu integrieren. Und ja, das ist eigentlich sehr trivial.

Im folgenden Ant-Script werden sowohl die Applikations-Jar (visualDependencies.one-jar.jar) als auch der JDBC-Treiber (ojdbc14.jar) in der Konfiguration vorbelegt. Selbstverständlich kann man alle Properties überschreiben bzw. das Script entsprechend anpassen.

Die wichtigen Teile sind: Das Ant-Jar-Command muss den Zusatz „update“ erhalten, denn die Ziel-Jar soll nicht ersetzt werden. Außerdem muss ein Fileset mit einer Verzeichnisstruktur angegeben werden, da die Treiber-Jar innerhalb der Ziel-Jar im Verzeichnis lib liegen muss (Struktur einer One-Jar). Das war’s.

Hinweis: Das Ant-File ist für den Gebrauch in einer Maven-Umgebung konfiguriert (basedir=../../../ entspricht dem Root-Verzeichnis bei der Annahme, dass Script unter src/main/scripts/ liegt).

<?xml version="1.0" encoding="UTF-8"?>
<project name="visualDependencies" default="help" basedir="../../../">
	<!-- The path of the actual artifact (project name), without the file suffix. -->
	<property name="project.name" value="visualDependencies.one-jar" />
	<!-- The path of the ojdbc driver, without the file suffix. -->
	<property name="ojdbc.name" value="ojdbc14" />
	<!-- DO NOT CHANGE THIS LINES UNLESS YOU KNOW WHAT YOU DO! -->
	<property name="project.jar" value="${project.name}.jar" />
	<property name="ojdbc.jar" value="${ojdbc.name}.jar" />
	<!-- Set actual paths of artifacts. -->
	<property name="application.path" location="${basedir}/target/${project.jar}" />
	<property name="ojdbc.parent.path" location="${basedir}/oracle" />
	<property name="ojdbc.path" location="${ojdbc.parent.path}/lib/${ojdbc.jar}" />
	<!-- Shows help (default target) -->
	<target name="help">
		<echo message="See http://www.knallisworld.de/blog/2010/11/23/eine-jar-ojdbc-nachtraglich-in-die-ziel-jar-integrieren/" />
		<echo message="Usage: attachOJDBC" />
	</target>
	<!-- Checks if the artifacts are available. Throws exceptions if they not exist. -->
	<target name="checkDependencies">
		<available file="${application.path}" property="application.exists" />
		<available file="${ojdbc.path}" property="ojdbc.exists" />
		<fail unless="application.exists" message="The application file (${application.path}) does not exist." />
		<fail unless="ojdbc.exists" message="The ojdbc file (${ojdbc.path}) does not exist." />
	</target>
	<!-- Integrates all files of ojdbc.parent.path into the target jar. -->
	<target name="attachOJDBC" depends="checkDependencies">
		<jar update="true" destfile="${application.path}">
			<fileset dir="${ojdbc.parent.path}" />
		</jar>
	</target>
</project>

Howto: Ein firmeneigenes Java-Maven-Repository aufsetzen

Für diesen Artikel setze ich jetzt einfach mal voraus, dass die Begriffe und Technologien hinter Java, Maven, Repository, Eclipse und Tomcat bekannt und geläufig sind. Und nein, jeweiliger Profi muss man zum Verständnis nicht sein.

Was wollen wir?

An ein firmeneigenes Repository — oder auch: corporate repository — gelten besondere Anforderungen. Diese können bei einem „einfach privat-eigenen“ verändert werden, aber man kommt meistens auf folgende Punkte:

  1. Ein Repository soll den Entwicklern zum Deployen der eigenen Artifakte und Module zur Verfügung gestellt werden. Wahlweise übernimmt dies auch ein automatischer Build-Agent wie Hudson, TeamCity und haste-nicht-gesehen.
  2. Ein Repositorymanager soll als proxy fungieren. In einer Firma spart dies nicht nur einfache Bandbreite. Da ein solcher Manager in der Regel im lokalen Netz steht, sind die Interaktionszeiten um ein Vielfaches besser.
  3. Ein so genanntes third party pepository für die Abhängigkeiten, die unbedingt notwendig sind und wovon es keine Maven-Abhängigkeiten gibt.

Für Punkt zwei spricht auch eine wesentlich einfachere Konfiguration der Clients (Entwicklerprofile), da nur noch ein Repository eingetragen werden muss. Alle „bekannten“ Repositories werden zentral gebündelt, damit schwindet natürlich gleichzeitig die „Freiheit“ des einzelnen Entwicklers, andere „unbekannte“ Repositories zu verwenden. Dies ist jedoch vernachlässigbar, weil: Diese „Freiheit“ schränkt im Endeffekt den Buildprozess und auch die Wiederverwendbarkeit ein. Das Hinzufügen von weiteren Repositories in die POM ist aus Gründen der Versionisierung und Nachhaltigkeit auch keine optimale Lösung. Dennoch, alles nur eine Sache der Konfigurations der Clients.

Was brauchen wir?

Es gibt eine Reihe von Repository-Managern, die allesamt viel können. Die Wahl auf Nexus fällt hier aus folgenden Gründen:

  • der Footprint ist mit 30 Megabyte wesentlich kleiner als bspw. Artifactory
  • die interne Verzeichnisstruktur entspricht mehr oder weniger 1:1 der realen Organisationsstruktur eines Maven-Repositorys (im Vergleich: Artifactory speichert ein eigenes Datenbankstruktur ähnliches Layout)
  • Nexus und das Eclipse-Plugin m2eclipse sind vom gleichen Hersteller Sonatype und ergänzen sich; nach dem Umstellen bemerkt der Entwickler keinen Unterschied in der Suche, Auto-Discovery, o.ä.

Eine umfangreiche Online-Dokumentation ist auf der Nexus-Seite zu finden.

Installation

Nexus wird unter anderem als WAR ausgeliefert, insofern die Installation in einen Tomcat ein leichtes ist. Beachtenswert ist dabei nur, dass Nexus ein Verzeichnis ~/sonatype-work erstellt. Da sich dort unter Umständen viele Nutzdaten ansammeln, kann ein Verschieben (symbolischer Link?) nicht verkehrt sein. Da sich mit der Laufe der Zeit einiges an Daten ansammeln kann, sollte der Platz nicht zu sparsam vermessen sein.

Umfang

Nachdem Tomcat bzw. Nexus gestartet ist, kann man sich mit dem Default-Daten admin/admin123 anmelden (analog mit den Daten der anderen beiden Benutzern!).

Nexus kommt bereits mit einer Reihen von vorkonfigurierten, eigenen hosted repositories einher.

  • releases sammelt alle Release-Artifakte der Firma
  • snapshots sammelt alle Snapshot-Artifakte der Firma
  • third-party sammelt alle Release-Artifakte externer Quellen, wofür es keine Maven-Repositories gibt (oder wo man jenes Repository nicht generell zur Verfügung stellen will), gutes Beispiel ist ein (aktueller) Oracle-JDBC-Treiber

Daneben gibt es so genannte proxy repositories, die praktisch gesehen nur aus einem Index bestehen. Wie ein Proxy hängen sie sich zwischen dem Client und dem tatsächlichen Repository und cachen alle Artifakte lokal. Selbst der Index ist mehrere Megabytes groß, das sollte man nicht vernachlässigen. Voreingetragene proxy repositories sind Apache Snapshots, Codehaus Snapshots, Central Maven Repository (Maven1/Maven2-Repository-Konverter sind in Nexus vorhanden a.k.a. virtual repositories).

Die grouped repositories sind auch rein virtuelle Gruppierungen von verschiedenen Repositories. Das Standard Repository „Public“ ist in der einfachsten Konfiguration eine Sammlung aller (aktivierten) Repositories auf dem Manager — also sowohl der externen Spiegel, der Third-Parties als auch den eigenen Artifakten.

Konfiguration

Die Aktivierung und Verwaltung von (neuen) Repositories ist abhängig der eigenen Bedürfnisse. Meistens sinnvoll ist es jedoch, bei den drei großen Spiegeln (proxy repositories) in dem Konfigurationstab das Indizieren (Download Remote Indexes) zu aktivieren. Je nach Belieben kann man in der Gruppe Administration auch das Aktualisierungsverhalten steuern.

Konfiguration: Deployment

Um ein Deployment zu gewährleisten, muss man nebst Kenntnis der Repository-URL (eben die URL) nur wissen, ob der anonyme Zugriff erlaubt sein soll, oder ob man einen Deployment-Benutzer einrichten und nutzen willst. Falls eine Richtlinie vorschreiben sollte, dass dies nur ein Build-Agent machen darf, ist ein (geheimes) Passwort oder Schlüssel unabdingbar.

Konfiguration: Client

Nehmen wir an, der Nexus-Manager ist auf dem Host 192.168.0.10:8080/nexus installiert. In der einfachen Installation und Konfiguration sammeln sich im public repository praktisch alle relevanten Artifakte (sowohl Releases als auch Snapshots).

<settings>
<mirrors>
<mirror>
<id>corporate</id>
<name>Corporate Repository</name>
<url>http://192.168.0.10:8080/nexus/content/groups/public</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>

Der Deployment-User benötigt ggf. Zugangsdaten für das entsprechende Repository.

Ein Client wie m2eclipse sollte danach einen kompletten Rebuild des Index machen.