Automatisierte virtuelle Testumgebungen mit Vagrant und Puppet

7 Kommentare

Das Problem kennt wohl jeder Entwickler:

Man arbeitet in einem Team – möglicherweise verteilt – an einer komplexen Anwendung die mehrere Infrstruktur-Komponenten umfasst. In den meisten, einfachen Fällen hat man zumindest schon Bedarf nach einer Datenbank und einem Application Server. Wird es komplexer kommen eventuell noch Komponenten wie eine Messaging Middleware oder ein NoSQL-Store hinzu. Meist installiert man sich als Entwickler alle Komponenten lokal, wenn man Glück hat ist die Installation und Konfiguration zumindest zum Teil von Skripten unterstützt. Oft wird diese „Kunst“ aber auch im Team von Mund zu Mund weitergegeben oder man muss sich durch schlecht oder lieblos gepflegte Wiki-Seiten hangeln. Selbst im besten Fall bleibt noch der Nachteil, dass sich das System insofern vom Test-, Staging- und Produktionssystem darin unterscheidet dass man alle Systeme auf einem Host betreibt. Mit Vagrant, einem Tool zum Erzeugen und Verteilen von virtuellen Umgebungen und Puppet, einer Software für Konfigurationsmanagement kann man hier Abhilfe schaffen. Dieser Artikel zeigt dies am Beispiel eines einfachen Java-Web-Stacks.


Update (Juni 2012): Der Code in Github ist aktualisiert um mit Vagrant-Versionen grösser 1.x zu arbeiten. Die Puppet-Manifeste wurden aktualisiert (kein Sun JDK mehr, Package-Updates).

Installation und erste Schritte

Die folgenden Beispiele enstanden auf einem Ubuntu 11.10, dürften mit Anpassungen aber leicht auch auf anderen Umgebungen lauffähig sein. Da Vagrant auf Ruby und VirtualBox aufbaut sollten beide vorher installiert sein. Anschliessend ist die Installation mit RubyGems der einfachste Weg:

> sudo gem install vagrant

Sollten bei der Installation Fehler auftreten, sind die Timestamps im gemspec-File ein heisser Kandidat. Nach der geglückten Installation kann man sofort loslegen:

> mkdir vagrant-test && cd vagrant-test
> vagrant init lucid64 http://files.vagrantup.com/lucid64.box

Mit vagrant init erzeugen wir im aktuellen Verzeichnis ein Default Vagrantfile, die Basis einer jeden Vagrant-Umgebung. Die letzten beiden Parameter geben den Namen der sog. Basebox an und die Adresse unter der sie geladen wird falls sie nicht vorher schon importiert wurde. Jede Vagrant-Konfiguration baut auf eine Basebox auf, von der ausgehend weitere Schritte erfolgen. Die Macher von Vagrant stellen auf ihrer Seite die 32 und 64bit Version von Ubuntu 10.04 (Lucid Lynx) zur Verfügung. Weitere Boxen findet man auf der Community-Seite vagrantbox.es, oder man macht sich die Mühe und baut sich eine eigene Basebox nach seinen Vorstellungen.

Der obige Befehl legt im Verzeichnis vagrant-test die Datei ‚Vagrantfile‘ an, die die Konfiguration der virtuellen Umgebung beinhaltet:

Vagrant::Config.run do |config|
 
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.
 
  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "lucid64"
 
  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  config.vm.box_url = "http://files.vagrantup.com/lucid64.box"
 
  # Boot with a GUI so you can see the screen. (Default is headless)
  # config.vm.boot_mode = :gui
 
  # ...
 
end

Anschliessend ist die erste virtuelle Umgebung nur noch einen Befehl entfernt:

> vagrant up
Konsolen-Output von 'vagrant up'

Konsolen-Output von 'vagrant up'

Die Warnung bezüglich der VirtualBox GuestAdditions kann man in den meisten Fällen ignorieren. Sollten doch Probleme auftreten kann man seine Basebox aktualisieren und neu paketieren.

Schliesslich kann man sich auf die erzeugte Box einloggen, kann sie wieder anhalten, oder sie löschen, wenn man sie nicht mehr benötigt oder wieder einen sauberen Stand braucht.

> vagrant ssh
> vagrant halt
> vagrant destroy

Der saubere Stand ist hier das Stichwort. In einem Projekt sollte für eine Testumgebung, auch für die lokale Entwicklerumgebung, ein definierter Stand existieren. Damit verhindert man die klassischen „bei mir hat es so funktioniert …“-Diskussionen und hat jederzeit die Möglichkeit diesen Stand wieder zu erzeugen. Auch hier kommt einem Vagrant entgegen, da es die Möglichkeit bietet im Vagrantfile einen Provisioning-Mechanismus zu konfigurieren der dann auf der erzeugten Box die Installation von Software und deren Konfiguration vornimmt. Derzeit unterstützt Vagrant entweder einfache Shell-Skripte, Chef Solo/Server oder eben Puppet. Pavlos Artikel Provisioning of Java web applications using Chef, VirtualBox and Vagrant beleuchtet die Verwendung von Vagrant mit Chef, dieser Artikel demonstriert die Verwendung von Puppet.

Multi-VM-Umgebungen

Ein grosser Vorteil von Vagrant ist, dass man nicht nur eine einzelne Box in einem Vagrantfile definieren kann, sondern ganze Umgebungen aus mehreren Boxen. Im Laufe des Artikels werden wir mit Hilfe von Vagrant und Puppet einen einfachen, typischen Stack für eine Java-Webanwendung aufbauen:

  • einen Datenbankserver mit einer MySQL-Instanz
  • einen Appserver mit einer Tomcat-Instanz

Die meisten Details finden sich im Artikel wieder, die vollständigen Sourcen des Beispiels gibt es auch bei Github.

Nachdem wir unsere Default-Box von vorher wieder zerstört haben editieren wir unser Vagranttfile wie folgt:

Vagrant::Config.run do |config|
 
  # base box and URL where to get it if not present
  config.vm.box = "lucid64"
  config.vm.box_url = "http://files.vagrantup.com/lucid64.box"
 
  # config for the appserver box
  config.vm.define "appserver" do |app|
    app.vm.boot_mode = :gui
    app.vm.network "33.33.33.10"
    app.vm.host_name = "appserver01.local"
    app.vm.provision :puppet do |puppet|
      puppet.manifests_path = "manifests"
      puppet.manifest_file = "appserver.pp"
    end
  end
 
  # config for the dbserver box
  config.vm.define "dbserver" do |db|
    db.vm.boot_mode = :gui
    db.vm.network "33.33.33.11"
    db.vm.host_name = "dbserver01.local"
    db.vm.provision :puppet do |puppet|
      puppet.manifests_path = "manifests"
      puppet.manifest_file = "dbserver.pp"
    end
  end
 
end

Wir konfigurieren zwei seperate Boxen für unsere beiden Server. Beide gehen von der zuvor importierten lucid64-Box aus und haben statische IP-Adressen. Ausserdem schalten wir für die zugrundeliegenden virtuellen Maschinen den GUI-Modus ein, da ein Problem mit VirtualBox manchmal dazu führt, dass Vagrant beim Starten hängt. Sollte die dazugehörige virtuelle Box schon hochgefahren sein kann man sich dort einfach mit vagrant/vagrant einloggen und ’sudo dhclient‘ ausführen, dann läuft Vagrant weiter.

Configuration Management mit Puppet

Für beide Maschinen legen wir im Verzeichnis manifests entsprechende Puppet-Manifeste an. Die grundsätzliche Einheit in einem Puppet-Manifest ist eine Resource. Sie besteht aus einem Typ, einem Titel und weiteren Parametern:

resource_type { "resource_title":
  param1 => 'value1',
  param2 => 'value2'
}

Resource können bei Puppet eine ganze Menge darstellen, z.B.

  • einfache Dateien, Verzeichnisse, Symlinks …
  • Benutzer und Gruppen
  • Pakete
  • Dienste
  • Cronjobs

Eine vollständige Liste aller Standard-Typen inklusive der möglichen Parameter findet man in der Puppet-Dokumentation. Sehen wir uns zuerst das Manifest für unseren Datenbank-Server an:

group { 'puppet': ensure => 'present' }
 
class mysql_5 {
 
  package { "mysql-server-5.1":
    ensure => present
  }
 
  service { "mysql":
    ensure => running,
    require => Package["mysql-server-5.1"]
  }
 
  exec { "create-db-schema-and-user":
    command => "/usr/bin/mysql -u root -p -e \"drop database if exists testapp; create database testapp; create user dbuser@'%' identified by 'dbuser'; grant all on testapp.* to dbuser@'%'; flush privileges;\"",
    require => Service["mysql"]
  }
 
  file { "/etc/mysql/my.cnf":
    owner => 'root',
    group => 'root',
    mode => 644,
    notify => Service['mysql'],
    source => '/vagrant/files/my.cnf'
  }
 
}
 
include mysql_5

Zuerst wird die Klasse mysql_5 definiert. Klassen können in Puppet genutzt werden um mehrere zusammengehörige Resourcen zu einer Einheit zusammenzufassen und diese später an einer geeignete Stelle einzubinden. Die erste Resource in unserer Klasse sorgt dafür, dass der Paket-Manager in unserem System (in diesem Fall apt-get) überprüft ob das Paket ‚mysql-server-5.1‘ installiert ist. Sollte das nicht der Fall sein wird Puppet die Installation für uns vornehmen. Der Parameter ensure gibt an was wir für dieses Paket für einen Zustand erwarten, also in diesem Fall dass es auf unserer Maschine vorhanden ist.

Die zweite Anweisung sorgt dafür dass der MySQL-Server-Dienst gestartet ist. Da es in Puppet keine garantierte Ausführungsreihenfolge gibt, sorgen wir mit dem require-Parameter dafür, dass diese Anweisung erst ausgeführt wird wenn zuvor schon die Installation des Pakets stattgefunden hat. Der Wert des Parameters referenziert unsere Paket-Resource. Im Gegensatz zu den Resourcen-Definitionen beginnen die Resourcen-Referenzen mit einem Grossbuchstaben.

Die nächste Resource beschreibt das Ausführen eines Befehls. Mit require versichern wir uns wieder, dass eine andere benötigte Resource – das Starten des MySQL-Servers – zuvor schon ausgeführt wurde. Dann legen wir mit einem einfachen SQL-Befehl das Schema und den Nutzer für unsere Applikation an. Optimalerweise würde man ein Skript mit den Befehlen zum Anlegen in einer Versionsverwaltung oder einem Artefakt-Repository vorhalten und es sich im Manifest von dort ziehen. Der Einfachheit halber sind die Befehle in diesem Beispiel aber direkt enthalten.

Mit der letzten Resource spielen wir unsere veränderte Konfiguration für MySQL ein, die dafür sorgt, dass unsere Instanz auch auf Verbindungen von ausserhalb lauscht. Das notify-Argument benachrichtig den Dienst das die Konfiguration geändert wurde und er sich neu starten soll.

Starten wir nun unsere DB-Box mit

> vagrant up dbserver

sehen wir folgenden Output:

Puppet-Output für das DB-Server-Setup

Puppet-Output für das DB-Server-Setup

Der Output von Puppet zeigt, dass das MySQL-Paket vom Status ‚purged‘ auf den Status ‚present‘ geändert wurde, dass unser Konfigurationsfile kopiert wurde und daraufhin der Service refresht wurde.

Um zu testen ob alles geklappt hat kann man sich auf die Datenbank des virtuellen Hosts verbinden (Passwort: dbuser):

> mysql -h 33.33.33.11 -u dbuser -p

In ähnlicher Weise setzen wir unseren Application-Server auf. Hier der Inhalt des Manifests:

group { 'puppet': ensure => 'present' }
 
class sun_java_6 {
 
  $release = regsubst(generate("/usr/bin/lsb_release", "-s", "-c"), '(\w+)\s', '\1')
 
  # adds the partner repositry to apt
  file { "partner.list":
    path => "/etc/apt/sources.list.d/partner.list",
    ensure => file,
    owner => "root",
    group => "root",
    content => "deb http://archive.canonical.com/ $release partner\ndeb-src http://archive.canonical.com/ $release partner\n",
    notify => Exec["apt-get-update"],
  }
 
  exec { "apt-get-update":
    command => "/usr/bin/apt-get update",
    refreshonly => true,
  }
 
  package { "debconf-utils":
    ensure => installed
  }
 
  exec { "agree-to-jdk-license":
    command => "/bin/echo -e sun-java6-jdk shared/accepted-sun-dlj-v1-1 select true | debconf-set-selections",
    unless => "debconf-get-selections | grep 'sun-java6-jdk.*shared/accepted-sun-dlj-v1-1.*true'",
    path => ["/bin", "/usr/bin"], require => Package["debconf-utils"],
  }
 
  package { "sun-java6-jdk":
    ensure => latest,
    require => [ File["partner.list"], Exec["agree-to-jdk-license"], Exec["apt-get-update"] ],
  }
 
}
 
class tomcat_6 {
  package { "tomcat6":
    ensure => installed,
    require => Package['sun-java6-jdk'],
  }
 
  package { "tomcat6-admin":
    ensure => installed,
    require => Package['tomcat6'],
  }
 
  service { "tomcat6":
    ensure => running,
    require => Package['tomcat6'],
    subscribe => File["mysql-connector.jar", "tomcat-users.xml"]
  }
 
  file { "tomcat-users.xml":
    owner => 'root',
    path => '/etc/tomcat6/tomcat-users.xml',
    require => Package['tomcat6'],
    notify => Service['tomcat6'],
    content => template('/vagrant/templates/tomcat-users.xml.erb')
  }
 
  file { "mysql-connector.jar":
    require => Package['tomcat6'],
    owner => 'root',
    path => '/usr/share/tomcat6/lib/mysql-connector-java-5.1.15.jar',
    source => '/vagrant/files/mysql-connector-java-5.1.15.jar'
  }
}
 
# set variables
$tomcat_password = '12345'
$tomcat_user = 'tomcat-admin'
 
include sun_java_6
include tomcat_6

In der Klasse ’sun_java_6′ wird in mehreren Schritten dafür gesorgt, dass Sun/Orcale Java in der Version 6 auf der Box installiert wird. Es wird das Ubuntu Partner Repository hinzugefügt, anschliessend ein ‚apt-get update‘ ausgeführt, damit das entsprechende Paket auch sichtbar ist und dann das Paket installiert (Quelle: http://offbytwo.com/2011/07/20/scripted-installation-java-ubuntu.html)

In der zweiten Klasse installieren wir Tomcat und die Tomcat-Manager-App und sorgen dafür dass der Tomcat-Service gestartet ist. Ausserdem benutzen wir ein Template, um die Datei tomcat-users.xml zu überschreiben. Im Template selbst steht an der für uns interessanten Stelle

<user name="<%= tomcat_user %>" password="<%= tomcat_password %>" roles="manager,admin"/>

Die Variablen werden im Manifest vor der Nutzung der Klasse gesetzt und dann beim Anlegen der Datei entsprechend gesetzt. Damit wir später auch mit unserem Datenbank-Server sprechen können fügen wir dem Tomcat-Classpath noch einen MySQL-Connector hinzu, der im Beispiel der Einfachheit halber auch wieder im files-Verzeichnis liegt. Wie oben gilt hier, dass man optimalerweise auf ein Repository zugreift, um das Projekt kompakt zu halten. Mit dem subscribe-Parameter am Service sorgen wir dafür, dass Tomcat sich bei bei Änderungen an den referenzierten Resourcen neu startet. Jetzt können wir auch unseren virtuellen Appserver starten:

> vagrant up appserver

Wenn alles geklappt hat kann man sich anschliessend unter http://33.33.33.10:8080/manager/html mit den vorher gesetzen Credentials (tomcat-admin/12345) in der Tomcat-Manager-App einloggen.

Damit steht unsere initiale Infrastruktur. Der Entwickler hat die Möglichkeit sich den Tomcat und die Datenbank z.B. in seine IDE einzubinden, mit Maven-Profilen zu arbeiten um Deployment- oder Datenbank-Update-Schritte direkt gegen die virtuelle Umgebung vorzunehmen oder einfach in den Umgebungen per Hand zu arbeiten

Werden die Umgebungen nicht mehr gebraucht, lassen sie sich wahlweise anhalten damit man sie später wieder mit dem selben Stand weiterverwenden kann oder man zerstört sie um wieder vom konfigurierten Ausgangszustand zu starten. Gibt man beim destroy keinen Box-Namen an werden alle im vorliegenden Vagrantfile definiereten Boxen gelöscht.

> vagrant halt 
> vagrant destroy 

Fazit

Der Vorteil eines solchen Setups liegt auf der Hand. Gesetzt den Fall dass man eine frei zugängige Basebox nutzt, oder man innerhalb der Organisation ein Artefakt-Repository pflegt in dem man auch seine eigenen Baseboxen ablegt, hat jeder neue Entwickler sofort die Möglichkeit sich nach Bedarf eine Testumgebung zu erzeugen. Auch Änderungen an Konfigurationen, hinzunehmen neuer Komponenten o.ä. kann leicht an das ganze Team verteilt werden, ohne dass man Gefahr läuft dass unterschiedliche Mitglieder unterschiedliche Stände pflegen. Einfach das Vagrant-Projekt unter Versionsverwaltung stellen, und jeder Entwickler bekommt Änderungen sofort mit und kann sich die neue Umgebung auf Knopfdruck erzeugen.

Denkt man die Idee konsequent weiter hat man einen weiteren Vorteil: auch gemeinsame genutzte Test-, QA-, Staging- und Produktions-Umgebungen lassen sich mit Puppet managen. Man kann also die Konfigurationen zentral in Zusammenarbeit von Entwicklung und Betrieb (das Stichwort DevOps musste ja noch kommen 😉 ) pflegen und dann auf allen Umgebungen nutzen. Das vermeidet kleine und grosse Differenzen auf den unterschiedlicchen Umgebungen und die daraus resultierenden Fehler. Im nächsten Artikel zu dem Thema werden wir einen genaueren Blick auf das Client/Server-Setup von Puppet werfen, mit man damit mehrere Umgebungen versioniert verwalten kann.

 

Kommentare

  • 18. Juni 2012 von Hendrik Ebbers

    Hi,
    wenn ich das ganze ausführe bekomme ich folgende Fehlermeldung:
    * The network type ‚33.33.33.10‘ is not valid. Please use
    ‚hostonly‘ or ‚bridged‘.

    Nachdem ich die IPs einfach mal auskommentiert hab, starten die VMs. Allerdings kann Java nicht installiert werden:

    notice: /Stage[main]/Sun_java_6/Package[debconf-utils]/ensure: ensure changed ‚purged‘ to ‚present‘
    notice: /Stage[main]/Sun_java_6/Exec[agree-to-jdk-license]/returns: executed successfully
    notice: /Stage[main]/Sun_java_6/File[partner.list]/ensure: defined content as ‚{md5}6b40260fb1c76397bef841ad845cd77e‘
    notice: /Stage[main]/Sun_java_6/Exec[apt-get-update]: Triggered ‚refresh‘ from 1 events
    err: /Stage[main]/Sun_java_6/Package[sun-java6-jdk]/ensure: change from purged to latest failed: Could not update: Execution of ‚/usr/bin/apt-get -q -y -o DPkg::Options::=–force-confold install sun-java6-jdk‘ returned 100: Reading package lists…
    Building dependency tree…
    Reading state information…
    Package sun-java6-jdk is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source
    E: Package sun-java6-jdk has no installation candidate
    at /tmp/vagrant-puppet/manifests/appserver.pp:35

    Ich hab mir das Projekt aus GIT ausgecheckt, kann also eigentlich nix falsch gemacht haben.
    Ich hab das ganze auf meinem MacBook ausprobiert und mir jeweils die neusten Versionen der Tools besorgt:
    Puppet 2.7.16
    Vagrant 1.0.3
    VirtualBox 4.1.16

    Hat irgendjemand eine Ahnung was ich falsch mache? Wär für jede Hilfe dankbar. Ich meine mich zu erinnern, dass Orales Java aus dem Paketmanager von Ubuntu entfernt wurde. Allerdings war das deutlich bevor dieser Artikel geschrieben wurde…

    • Bastian Spanneberg

      18. Juni 2012 von Bastian Spanneberg

      Hi Hendrik,

      das Beispiel wurde noch mit einer älteren Version von Vagrant erstellt. In der aktuellen Syntax muss es an der betroffenen Stelle heissen:

      app.vm.network :hostonly, „33.33.33.10“

      Was Java angeht: Ich erinnere mich gelesen zu haben dass die Java 6 Paktete aus den Packages entfernt wurden, d.h. die Lösung funktoniert leider so nicht mehr. Ich werde zusehen den Artikel demnächst mal auf den neuesten Stand zu bringen und eine neue Lösung für die Java-Installation einzubauen.

      Danke jedenfalls für die Kommentare und die Erinnerung dass ich es mal aktualisieren muss 😉

  • 18. Juni 2012 von Hendrik Ebbers

    Den DB-Server bekomm ich auch nicht ans laufen. Hier kommt folgende Fehlermeldung:

    err: /Stage[main]/Mysql_5/File[/etc/mysql/my.cnf]/ensure: change from absent to file failed: Could not set ‚file on ensure: No such file or directory – /etc/mysql/my.cnf.puppettmp_3157 at /tmp/vagrant-puppet/manifests/dbserver.pp:25
    err: /Stage[main]/Mysql_5/Package[mysql-server-5.1]/ensure: change from purged to present failed: Execution of ‚/usr/bin/apt-get -q -y -o DPkg::Options::=–force-confold install mysql-server-5.1‘ returned 100: Reading package lists…
    Building dependency tree…
    Reading state information…
    The following extra packages will be installed:
    libdbd-mysql-perl libdbi-perl libhtml-template-perl libmysqlclient16
    libnet-daemon-perl libplrpc-perl mysql-client-5.1 mysql-client-core-5.1
    mysql-common mysql-server-core-5.1
    Suggested packages:
    dbishell libipc-sharedcache-perl tinyca mailx
    The following NEW packages will be installed:
    libdbd-mysql-perl libdbi-perl libhtml-template-perl libmysqlclient16
    libnet-daemon-perl libplrpc-perl mysql-client-5.1 mysql-client-core-5.1
    mysql-common mysql-server-5.1 mysql-server-core-5.1
    0 upgraded, 11 newly installed, 0 to remove and 23 not upgraded.
    Need to get 24.2MB of archives.
    After this operation, 61.0MB of additional disk space will be used.
    Err http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main mysql-common 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.91.25 80]
    Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid/main libnet-daemon-perl 0.43-1 [46.9kB]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main mysql-common 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Get:2 http://us.archive.ubuntu.com/ubuntu/ lucid/main libplrpc-perl 0.2020-2 [36.0kB]
    Get:3 http://us.archive.ubuntu.com/ubuntu/ lucid/main libdbi-perl 1.609-1build1 [801kB]
    Err http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main libmysqlclient16 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.91.25 80]
    Get:4 http://us.archive.ubuntu.com/ubuntu/ lucid/main libdbd-mysql-perl 4.012-1ubuntu1 [137kB]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main libmysqlclient16 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Err http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main mysql-client-core-5.1 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.91.25 80]
    Get:5 http://us.archive.ubuntu.com/ubuntu/ lucid/main libhtml-template-perl 2.9-1 [65.8kB]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main mysql-client-core-5.1 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main mysql-client-5.1 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main mysql-server-core-5.1 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Err http://security.ubuntu.com/ubuntu/ lucid-security/main mysql-server-5.1 5.1.62-0ubuntu0.10.04.1
    404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-common_5.1.62-0ubuntu0.10.04.1_all.deb 404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/libmysqlclient16_5.1.62-0ubuntu0.10.04.1_amd64.deb 404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-client-core-5.1_5.1.62-0ubuntu0.10.04.1_amd64.deb 404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-client-5.1_5.1.62-0ubuntu0.10.04.1_amd64.deb 404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-server-core-5.1_5.1.62-0ubuntu0.10.04.1_amd64.deb 404 Not Found [IP: 91.189.92.184 80]
    Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-server-5.1_5.1.62-0ubuntu0.10.04.1_amd64.deb 404 Not Found [IP: 91.189.92.184 80]
    Fetched 1086kB in 7s (136kB/s)
    E: Unable to fetch some archives, maybe run apt-get update or try with –fix-missing?

    notice: /Stage[main]/Mysql_5/Service[mysql]: Dependency File[/etc/mysql/my.cnf] has failures: true
    notice: /Stage[main]/Mysql_5/Service[mysql]: Dependency Package[mysql-server-5.1] has failures: true
    warning: /Stage[main]/Mysql_5/Service[mysql]: Skipping because of failed dependencies
    notice: /Stage[main]/Mysql_5/Exec[create-db-schema-and-user]: Dependency File[/etc/mysql/my.cnf] has failures: true
    notice: /Stage[main]/Mysql_5/Exec[create-db-schema-and-user]: Dependency Package[mysql-server-5.1] has failures: true
    warning: /Stage[main]/Mysql_5/Exec[create-db-schema-and-user]: Skipping because of failed dependencies
    notice: Finished catalog run in 9.00 seconds

    Ich habe mal ein wget ausprobiert, das schlägt auch fehl:
    wget http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-common_5.1.62-0ubuntu0.10.04.1_all.deb
    –2012-06-18 20:04:06– http://security.ubuntu.com/ubuntu/pool/main/m/mysql-dfsg-5.1/mysql-common_5.1.62-0ubuntu0.10.04.1_all.deb
    Resolving security.ubuntu.com… 91.189.92.184, 91.189.92.151, 91.189.92.166, …
    Connecting to security.ubuntu.com|91.189.92.184|:80… connected.
    HTTP request sent, awaiting response… 404 Not Found
    2012-06-18 20:04:16 ERROR 404: Not Found.

    Echt schade. Find den Artikel absolut super, die Skripte laufen nur irgendwie mom. nicht…

    • Bastian Spanneberg

      18. Juni 2012 von Bastian Spanneberg

      Danke für den Hinweis, ich schaue mir das die Tage mal an und werde auch hier aktualisieren. Der Fehler ist mir neu und scheint mir auch mit geänderten Packages zu tun zu haben. Ich werd‘ der Sache auf den Grund gehen.

  • 2. Juli 2012 von Nils

    33.33.33.11 ist eine IP Adresse die dem US Verteidigungsministerium zugewiesen ist (33.0.0.0/8). Besser ist es sich ein Netz aus den folgenden Bereichen zu nehmen:

    192.168.0.0/24
    10.0.0.0/8
    172.16.0.1/12

    je nachdem wie das lokale netzwerk aufgesetzt ist.

  • Hi Bastian,
    da du dich ja für Vagrant / Java interessierst, könnte folgendes sehr interessant für dich sein: https://github.com/guigarage/vagrant-binding

    • Bastian Spanneberg

      4. Dezember 2012 von Bastian Spanneberg

      Hi Hendrik. Sieht auf den ersten Blick schon mal spannend aus. Danke für den Hinweis 🙂

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.