Die Qualität der jeder Webseite zugrundeliegende Server-Infrastruktur bildet einen wichtigen Grundstein für jedes Internet-Projekt und trägt entscheidend zum Erfolg eines Internet-Unternehmens bei.

Neben der Geschwindigkeit, Sicherheit und Stabilität ist die Flexibilität und Skalierbarkeit ein wichtiger Baustein zur perfekten Serverlandschaft. Optimale Skalierbarkeit und Flexibilität bietet das seit einigen Jahren unter dem Namen „Cloud-Hosting“ bekannt gewordene Modell des Server-Hostings.

Im Vergleich zum herkömmlichen Webhosting auf dedizierten oder virtuellen Servern, die nur über vorher definierte und begrenzte Ressourcen verfügen, kann beim Cloud-Hosting die Anzahl der Server, sowie die pro Server verfügbaren Ressourcen wie CPU, Arbeitsspeicher oder Festplattengröße zu jeder Zeit beliebig angepasst und konfiguriert werden.

Dies schafft die Möglichkeit zur Skalierung nach Bedarf. Das bedeutet, wenn zu einem Zeitpunkt mehr Traffic erwartet wird und somit mehr Ressourcen benötigt werden, kann man weitere Server und Ressourcen auf Knopfdruck zur Verfügung stellen. Bekannte Anbieter des Cloud-Hostings sind Amazon mit der Elastic Compute Cloud (EC2), Google mit der Compute Engine (GCE), Softlayer oder Rackspace.

Im Frühjahr 2014 sind wir mit Stetic und unserer kompletten Server-Infrastruktur zu Google’s Compute Engine (GCE) umgezogen und waren sehr glücklich und zufrieden damit. Obwohl wir aus datenschutzrechtlichen Gründen aktuell wieder bei einem deutschen Anbieter sind, können wir die Compute Engine von Google rein technisch und unternehmerisch – abgesehen vom Datenschutz in Deutschland – uneingeschränkt empfehlen.

Während des zehnjährigen Bestehens von Stetic haben wir einige Anbieter getestet und genutzt, darunter auch viele vergleichbare Angebote zu GCE, aber was wir bei Google vorgefunden haben stellt technisch gesehen alles andere in den Schatten.

Um genauer zu werden, möchte ich dir hier zehn der größten Vorteile beschreiben, die Google mit der Compute Engine bietet:

1. Optimale Performance mit SSD-Festplatten

Festplatten können bei einem Server zum Flaschenhals werden und viel zur Optimierung der Geschwindigkeit beitragen. Waren bis vor einigen Jahren noch SCSI- oder SAS-Festplatten das Optimum für einen Serverbetrieb, so sind es heute die SSD-Festplatten. Gerade, aber nicht nur bei dynamischen Inhalten und Datenbankanwendungen sollte diese Festplattenart jeder anderen vorgezogen werden. Es ist schon fast unverständlich wie einige Webhoster heute noch mit hoher Performance werben und dennoch nur Server mit SATA-Platten anbieten.

Zurück zu Google: Die Compute Engine bietet die Einbindung von SSD-Festplatten für jeden virtuellen Server bzw. jede Art von Maschine an. Hierbei wird zwischen Solid-state persistent disks (SSD) und Local SSDs unterschieden. Local SSDs sind lokal an die virtuelle Maschine gebunden und dadurch sehr effizient im Datendurchsatz, haben eine fixe Größe und können nicht über Snapshots gesichert werden. Sie eigenen sich wunderbar als Cache oder für eine Datenbank-Replikation über mehrere Server. Solid-state persistent disks hingegen sind in der Größe veränderbar, redundant und können mit einem Snapshot zu jeder Zeit gesichert werden. Sie eigen sich daher für alle Anwendungsgebiete, bei denen Wert auf hohe Geschwindigkeit und Sicherheit gelegt wird.

In dem ganzen Jahr in dem wir Stetic in der Google Compute Engine gehostet haben, haben wir lediglich einmal ein Problem mit einer Festplatte feststellen können, was bei 9 Maschinen in 365 Tagen und bei SSD-Festplatten eher gering ist. Da der Server aber redundant war, war das Problem nach einem Snapshot und Hochfahren einer neuen Maschine mit diesem Snapshot innerhalb von 10 Minuten gelöst. Zudem war die Performance der Platten immer konstant.

2. Schnelles Netzwerk und optimale Anbindung

Google sagt von sich selbst, es betreibt das grösste, schnellste und fortschrittlichste Computer-Netzwerk der Welt. Wenn man einmal die Compute Engine benutzt hat, glaubt man das uneingeschränkt. Die Verfügbarkeit, die hohe Geschwindigkeit und auch das Handling des Netzwerkes sind immer gegeben. Zudem hat Google an alle Knotenpunkte eine gute Anbindung, was sich gerade nach Übersee extrem bemerkbar macht.

Obwohl unsere Server in einem Google-Rechenzentrum im Irland gehostet waren, sind die Verbindungszeiten und Geschwindigkeiten mit denen der besten deutschen Hoster durchaus vergleichbar und ein Unterschied nicht merkbar gewesen. Über den Ozean, also beispielsweise von Irland in die USA, waren die Geschwindigkeiten sogar um einiges besser als bei deutschen Anbietern. Das liegt sicher auch daran, das Google nicht über das öffentliche Netzwerk verbinden muss, sondern sein eigenes privates globales Netzwerk nutzen kann.
Sollte Google nun noch ein Rechenzentrum in Deutschland für GCE zur Verfügung stellen, wäre das nochmals ein Performance-Gewinn und somit für deutsche Kunden sehr zu begrüßen.

3. Hohe Sicherheit durch eigene interne Netzwerke

Eigentlich passt dieser Punkt mit zum letzten, hat aber für uns so einen hohen Stellenwert und Nutzen, dass dieses Feature einfach gesondert erwähnt werden muss. Die Möglichkeit mehrere Server privat untereinander zu vernetzen und sogar private Netze, Routing und Firewall-Regeln uneingeschränkt vergeben und konfigurieren zu können, verringert nicht nur den Aufwand und verbessert das Handling und die Sicherheit; dieses Feature ist in dieser Form so – ausgenommen Amazon – bei keinem normalen Hosting-Anbieter vorzufinden. Und wenn, dann nur mit hohen Zusatzkosten.

Es ist mir unverständlich wieso andere Anbieter dieses Feature derart vernachlässigen, da ein Hosting mehrerer Server immer eine Kommunikation der Server untereinander mit sich bringt. Und diese Kommunikation muss sicher sein, sei es eine Verbindung zur Datenbank oder zu anderen Diensten: Interne Verbindungen müssen abgesichert, jederzeit möglich und erweiterbar sein. Google hat dies wunderbar umgesetzt und das Handling einfach, verständlich und flexibel gestaltet: Standardmäßig ist ein Default-Netzwerk angelegt, dem alle Maschinen automatisch zugeordnet werden können. Man kann eigene Netzwerke inkl. eigenen privaten IP-Adressen, Firewalls und Routings anlegen und jeder Maschine zuordnen. Auch eine Region-übergreifende Verbindung ist damit möglich und enthalten. Besser geht es nicht!

4. Einfache Lastenverteilung und Hochverfügbarkeit

Die Möglichkeit der Lastenverteilung und Hochverfügbarkeit ist gerade für skalierbare Systeme ein unumgängliches Feature. Wie schön, das Google dies von Haus aus bietet und mit integrierten Load-Balancern auch hier die Einrichtung zum Kinderspiel macht. Ob Netzwerklastenausgleich für alle Arten der Lastenverteilung mit TCP oder UDP und beliebige Ports oder HTTP-Lastenausgleich zum Verteilen des Traffic’s auf mehrere Webserver mit allen notwendigen Konfigurationsmöglichkeiten – alles ist möglich und einfach zu administrieren.

5. Günstiger im Vergleich zu anderen Anbietern

Das Preismodell der Compute Engine ist im Vergleich zu anderen Cloud-Anbietern wesentlich günstiger und vorteilhafter gestaltet. Durch Ermässigungen, die sich je nach Nutzung pro Monat erheblich steigern, bekommt man in mehreren Stufen einen Rabatt auf den tatsächlichen Preis. So zahlt man während der Nutzung von 25%-50% des Monats während dieser Zeit 80% des Ursprungspreises, bei 50%-75% 60% und bei 75%-100% nur noch 40% vom Preis pro Maschine. Im Vergleich zu Amazon haben wir so gefühlt nur den halben Preis pro Monat gezahlt und mussten uns auch nicht, wie bei Amazon, zur Preisreduzierung an längere Vertragslaufzeiten binden.

6. Schnelle Verfügbarkeit neuer Instanzen durch schnelle Bootzeiten

Neue Instanzen bzw. Maschinen sind in der Compute Engine über die API und auch über das Webinterface rasend schnell angelegt und verfügbar. Das Booten einer Maschine dauert in aller Regel weniger als 30 Sekunden, bei manchen hatten wir sogar sagenhafte 15 Sekunden gemessen, bis wir uns auf der Maschine per SSH einloggen konnten. Das liegt natürlich auch an den verwendeten SSD-Festplatten, die man für alle Maschinen unbedingt immer wählen sollte. Sicher spielt auch die Software von Google und die Geschwindigkeit und Verfügbarkeit der API hier eine große Rolle.
Gerade, wenn man schell neue Ressourcen benötigt, ist diese Tatsache ein riesiger Pluspunkt.

7. Einfache Konfiguration mit Puppet

Mit Amazon und anderen Anbietern hatten wir so unsere Probleme, geeignete Puppet-Module mit allen in der API zur Verfügung stehenden Funktionen als Open-Sorce-Modul zu finden. Nicht so bei Google. Hier ist das umfangreiche Modul puppetlabs-gce_compute vorhanden, welches nahezu alle Funktionen der Compute Engine API abbildet. Dies ermöglicht das Erstellen von Maschinen inklusive aller zugehörigen Services und das anschliessende automatische Konfigurieren der Maschinen. Unsere Erfahrungen haben wir in einem Blogartikel zur Automation von Google Compute Engine mit Puppet anhand eines hochverfügbaren LAMP Stack’s mit MongoDB beschrieben und die Funktionsweisse mit allen notwendigen Beispielen erklärt.

8. Nutzerfreundliches Interface, starke API und einfaches Handling

Das Handling der Google Compute Engine ist immer leicht und einfach zu verstehen. Das beginnt schon bei den Namen der Maschinen, die beliebig vergeben werden können und sogleich als Hostname innerhalb des eigene Netzwerkes vergeben und unter einen eigenen internen Domain verfügbar sind. Wo andere Anbieter zufällige ID’s vergeben, die sich schwer merken lassen, macht die Vergabe von Namen in der GCE die Kommunikation unter den Servern und die Handhabung sehr einfach.
Auch das Webinterface und die API sind einfach zu verstehen, wie die meisten Services von Google: Minimale optische, aber dennoch schöne Darstellung, eine klare Benutzerführung und optimale Performance lassen einen niemals den Überblick verlieren und erleichtern jedem den Einstieg. Alles in allem macht es viel Spaß, damit zu arbeiten und ermöglicht ein effizientes Arbeiten.

9. Auto Restart und Live Migration

Sollte Google einmal Wartungsarbeiten durchführen müssen oder ein Software-Update des Wirtsystems notwendig ist, so bedeutet dies nicht zwangsläufig, dass der Server neu gestartet werden muss. Man hat hier die Wahl, ob der Server im Betrieb migriert werden soll oder ob er automatisch heruntergefahren und nach den Wartungsarbeiten wieder gestartet werden soll. Bei der Migration wird die virtuelle Maschine im Betrieb auf ein anderes System transferiert, welches von den Wartungsarbeiten nicht betroffen ist. Währen dieses Umzuges kann mit einer geringen Performance-Einbuße gerechnet werden, der Server bleibt aber online.

Sollte es einmal Software oder Hardwareprobleme geben, kann der Maschine über die Einstellung „automaticRestart“ mitgeteilt werden, in diesem Fall automatisch wieder neu zu starten. Dies ist sehr hilfreich wenn der Server aufgrund eines Problems heruntergefahren oder abgestürzt ist.

10. Google hat die meisten und besten Erfahrungen

Google hat nicht nur die meiste und beste Erfahrung mit dem Betrieb von Internet-Projekten, sondern betreibt mit geschätzt mehr als 1 Million Servern auch die größte Anzahl von Servern.
Es scheint nur logisch, das dieser Bereich mit all seinen Möglichkeiten bis in den letzten Millimeter optimiert und auf hohe Performance, Sicherheit und Hochverfügbarkeit ausgelegt ist. Zudem beschäftigt Google die besten Ingenieure, um den Betrieb und die Weiterentwicklung sicherzustellen. Erinnerst du dich an lange Ladezeiten einer Google-Webseite oder gar einen Ausfall? Ich kann mich vielleicht wenn es hoch kommt während der letzten 15 Jahre an ein bis zwei kurze Downtimes erinnern, der letzte im August 2013, was bei der Menge an Servern und Ablegern sehr sehr wenig ist.
Genau dieses Wissen, die Erfahrung und die Technik stellt Google Ihren Kunden mit der Compute Engine zur Verfügung. Fast schon unglaublich, dass es möglich ist, die gleiche Infrastruktur wie Google zu nutzen und für seine eigenen Projekte nutzen zu können.

Ein Nachteil: Kein Rechenzentrum in Deutschland

So gerne wir auch bei der Compute Engine und bei Google geblieben wären, die Tatsache das Google keine Region in Deutschland anbietet und den in Deutschland doch recht verbreiteten Vorbehalten gegenüber dem Unternehmen Google, haben uns leider zum Umzug zu einem deutschen Anbieter bewogen. Da wir für unsere Kunden viel Wert auf Datenschutz legen, sind die genannten Tatsachen für uns nicht tragbar gewesen. Zwar werden alle Festplatten laut Google verschlüsselt, Zertifikate über die Sicherheit ausgestellt und die Datenintegrität nach Industriestandard sichergestellt, dennoch stehen viele Menschen in Deutschland und Europa Google mit einer gewissen Skepsis gegenüber.

Encryption

All data written to disk in Compute Engine is encrypted on the fly and then transmitted and stored in encrypted form. Compute Engine has completed ISO 27001, SSAE-16, SOC 1, SOC 2, and SOC 3 certifications, demonstrating our commitment to information security.

Data integrity

Compute Engine uses redundant, industry-standard mechanisms to protect persistent disk users from data corruption and from sophisticated attacks against data integrity.

Ich hoffe, dass sich dies in Zukunft ändern wird und ich mit diesem Artikel einen Teil dazu beitragen konnte. Vielleicht bietet Google die Compute Engine bald mit Rechenzentren in Deutschland an und macht passende Kampagnen zu Datenschutz und Sicherheit der Daten. Dann könnte sich das Blatt und die Einstellung der Menschen dazu wenden.

For our Web Analytics Tool Stetic we are always looking for new flexible hosting solutions and just found Google’s Compute Engine as the perfect place for our needs. On Google Compute Engine you can launch virtual machines on Google’s infrastructure with great performance, high flexibility, strong security and a good price/performance ratio. The biggest advantage is the possibility to scale your systems whenever you need. From our point of view and compared to other cloud computing competitors Google has also the most user-friendly interface and a great set of tools to get you started easily.

With Puppet, the tool of our choice for server management, you can easily define and create your cluster of Compute instances and get the software installed and configured quickly. In this blog post we want to share our learnings on how to setup a high available LAMP Stack with MongoDB on Google’s Compute Engine with Puppet Open Source.

Prerequisites

Before we get started you need a Google Account, a Compute Engine enabled project and some software installed:

1. Create Google Account
   If you don’t already have an account, just sign up for a new Google Acccount.
2. Create Project
   Login with your account at the Google Developers Console, create a project with Compute Engine and billing enabled.
3. Install Google Cloud SDK
   Download and install The Google Cloud SDK and authenticate to Google Cloud Platform by running gcloud auth login.
4. Install Puppet
   To get started with puppet, you need a local Puppet installation. Depending on your OS this can vary. For Debian or Ubuntu you can just apt-get install puppet, for other OS’s please refer to Installing Puppet: Pre-Install Tasks

Setup

With the installed Puppet and authenticated Cloud SDK we can now setup our local Puppet environment. First you have to install the Google Compute Engine Module from Puppetlabs by running
puppet module install puppetlabs-gce_compute
Then create a device.conf in your Puppet configuration path. To determine the location of this file, just run
puppet apply --configprint deviceconfig
This should give you a path like /etc/puppet/device.conf or ~/.puppet/device.conf.

#/etc/puppet/device.conf
[my_project]
  type gce
  url [/dev/null]:project_id

In the section header my_project you can choose any name associated with your project. This is the name of the certificate and will be used in the future to select the right project when connecting to GCE.
Within the element url just change project_id to your chosen project id.

Creating the Puppet Master (Open Source)

Now it’s time to create a instance for the Puppet master. The Puppet master will be the management server for all our instances with the running Puppet agents and should therefore be reachable from the instances over the network. Every Puppet agent polls the configuration (catalog) from the master and start running it if compilation succeeded. We choose "f1-micro" as the machine type with 1 shared CPU, 0.6 GB RAM and with the default 10 GB sized boot disk. This should be enough for a Puppet master with up to 20 agents. If you like to run a higher amount of agents or any other service on this machine that needs some capacity you should choose a higher machine type.

Create your first puppet manifest file puppetmaster_up.pp with the following contents:

# The Puppet master
gce_instance { 'puppet-master':
  ensure                => present,
  description           => 'Puppet Master Open Source',
  machine_type          => 'f1-micro',
  zone                  => 'europe-west1-b',
  network               => 'default',
  auto_delete_boot_disk => false,
  tags                  => ['puppet', 'master'],
  image                 => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
  manifest              => "include gce_compute_master",
  startupscript         => 'puppet-community.sh',
  puppet_service        => present,
  puppet_master         => "puppet-master",
  modules               => ['puppetlabs-inifile', 'puppetlabs-stdlib', 'puppetlabs-apt', 'puppetlabs-concat', 'saz-locales'],
  module_repos          => { 
    'gce_compute'        => 'git://github.com/stetic/puppetlabs-gce_compute', 
    'gce_compute_master' => 'git://github.com/stetic/puppet-gce_compute_master',
    'mongodb'            => 'git://github.com/puppetlabs/puppetlabs-mongodb'
  }
}

Most of the code should be self-explaining: We create a new Google Compute Instance called „puppet-master“, ensure that it’s present, set the machine type, the zone where the instance should be started (More Info: Regions & Zones), the default network, some tags to identify the machine later, the image with Debian 7 Backports and add some puppet specific configuration and modules. For more information about all available options refer to the puppetlabs/gce_compute Usage Section.

In the module_repos option we add a minimal modified version of the gce_compute module from Github which adds support for disk types to use SSD disks, multiple disks and adds an auto_delete_boot_disk option. The second repo gce_compute_master is needed to create a Puppet Master from the Open Source version of puppet which is not provided by the gce_compute module.

Now we can create and start our first GCE instance with the following command. Instead of my_project use the previously defined certificate name:
puppet apply --certname my_project puppetmaster_up.pp

If everything is running fine, you should see a similar message like this:
Notice: Compiled catalog for my_project in environment production in 0.17 seconds
Notice: /Stage[main]/Main/Gce_instance[puppet-master]/ensure: created
Notice: Finished catalog run in 21.18 seconds

You can now ssh into your new created instance by typing
gcutil ssh puppet-master

Connected to puppet-master you should check if a puppet agent and a puppet master process is running. All puppet logging goes to /var/log/syslog.

In order to have access to the GCE API, the Puppet Master has to be authorized to the Google Cloud. It’s the same procedure as on your local machine, except the sudo:
sudo gcloud auth login

Now create a Puppet manifest on the master to define the instances. The following manifest will create two web nodes, three MongoDB nodes, a firewall rule to allow incoming connections on port 80 and a load balancing for the two web servers in the Europe Zone:

# /etc/puppet/manifests/cluster_up.pp
#
# LAMP cluster on GCE with Apache and MongoDB replica set
#
# Disks

gce_disk { 'disk-mongodb1':
  ensure               => present,
  description          => 'mongodb1:/var/lib/mongodb',
  size_gb              => '100',
  zone                 => 'europe-west1-b',
  disk_type            => 'pd-ssd',
  wait_until_complete  => true
}

gce_disk { 'disk-mongodb2':
  ensure               => present,
  description          => 'mongodb2:/var/lib/mongodb',
  size_gb              => '100',
  zone                 => 'europe-west1-a',
  disk_type            => 'pd-ssd',
  wait_until_complete  => true
}

gce_disk { 'disk-mongodb3':
  ensure               => present,
  description          => 'mongodb3:/var/lib/mongodb',
  size_gb              => '100',
  zone                 => 'europe-west1-a',
  disk_type            => 'pd-ssd',
  wait_until_complete  => true
}

# Instances
gce_instance { 'web1':
  ensure                => present,
  machine_type          => 'g1-small',
  zone                  => 'europe-west1-b',
  network               => 'default',
  boot_disk_type        => 'pd-ssd',
  auto_delete_boot_disk => false,
  tags                  => ['apache', 'web'],
  image                 => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
  manifest              => '',
  startupscript         => 'puppet-community.sh',
  puppet_service        => present,
  puppet_master         => $fqdn
}

gce_instance { 'web2':
    ensure                => present,
    machine_type          => 'g1-small',
    zone                  => 'europe-west1-a',
    network               => 'default',
    boot_disk_type        => 'pd-ssd',
    auto_delete_boot_disk => false,
    tags                  => ['apache', 'web'],
    image                 => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
    manifest              => '',
    startupscript         => 'puppet-community.sh',
    puppet_service        => present,
    puppet_master         => $fqdn
}

gce_instance { 'mongodb1':
  ensure                    => present,
  machine_type              => 'n1-highmem-2',
  zone                      => 'europe-west1-b',
  network                   => 'default',
  require                   => Gce_disk['disk-mongodb1'],
  disk                      => 'disk-mongodb1,deviceName=mongodb',
  boot_disk_type            => 'pd-ssd',
  auto_delete_boot_disk     => false,
  tags                      => ['mongodb', 'database', 'primary'],
  image                     => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
  manifest                  => 'exec { "mkdir-var-lib-mongodb":
    command => "/usr/bin/sudo /bin/mkdir -p /var/lib/mongodb"
  }
  exec { "safe_format_and_mount":
    command => "/usr/bin/sudo /usr/share/google/safe_format_and_mount -m \"mkfs.ext4 -F\" /dev/disk/by-id/google-mongodb /var/lib/mongodb",
    require => Exec["mkdir-var-lib-mongodb"]
  }',
  startupscript             => 'puppet-community.sh',
  puppet_service            => present,
  puppet_master             => $fqdn
}

gce_instance { 'mongodb2':
  ensure                    => present,
  machine_type              => 'n1-highmem-2',
  zone                      => 'europe-west1-a',
  network                   => 'default',
  require                   => Gce_disk['disk-mongodb2'],
  disk                      => 'disk-mongodb2,deviceName=mongodb',
  boot_disk_type            => 'pd-ssd',
  auto_delete_boot_disk     => false,
  tags                      => ['mongodb', 'database', 'member'],
  image                     => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
  manifest                  => 'exec { "mkdir-var-lib-mongodb":
    command => "/usr/bin/sudo /bin/mkdir -p /var/lib/mongodb"
  }
  exec { "safe_format_and_mount":
    command => "/usr/bin/sudo /usr/share/google/safe_format_and_mount -m \"mkfs.ext4 -F\" /dev/disk/by-id/google-mongodb /var/lib/mongodb",
    require => Exec["mkdir-var-lib-mongodb"]
  }',
  startupscript             => 'puppet-community.sh',
  puppet_service            => present,
  puppet_master             => $fqdn
}

gce_instance { 'mongodb3':
  ensure                    => present,
  machine_type              => 'n1-highmem-2',
  zone                      => 'europe-west1-a',
  network                   => 'default',
  require                   => Gce_disk['disk-mongodb3'],
  disk                      => 'disk-mongodb3,deviceName=mongodb',
  boot_disk_type            => 'pd-ssd',
  auto_delete_boot_disk     => false,
  tags                      => ['mongodb', 'database', 'member'],
  image                     => 'projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140814',
  manifest                  => 'exec { "mkdir-var-lib-mongodb":
    command => "/usr/bin/sudo /bin/mkdir -p /var/lib/mongodb"
  }
  exec { "safe_format_and_mount":
    command => "/usr/bin/sudo /usr/share/google/safe_format_and_mount -m \"mkfs.ext4 -F\" /dev/disk/by-id/google-mongodb /var/lib/mongodb",
    require => Exec["mkdir-var-lib-mongodb"]
  }',
  startupscript             => 'puppet-community.sh',
  puppet_service            => present,
  puppet_master             => $fqdn
}

#
# Firewall
#
gce_firewall { 'allow-http':
    ensure      => present,
    network     => 'default',
    description => 'allows incoming HTTP connections',
    allowed     => 'tcp:80',
}

#
# Load balancer
#
gce_httphealthcheck { 'basic-http':
    ensure       => present,
    require      => Gce_instance['web1', 'web2'],
    description  => 'basic http health check',
}
gce_targetpool { 'web-pool':
    ensure        => present,
    require       => Gce_httphealthcheck['basic-http'],
    health_checks => 'basic-http',
    instances     => 'europe-west1-b/web1,europe-west1-a/web2',
    region        => 'europe-west1',
}
gce_forwardingrule { 'web-rule':
    ensure       => present,
    require      => Gce_targetpool['web-pool'],
    description  => 'Forward HTTP to web instances',
    port_range   => '80',
    region       => 'europe-west1',
    target       => 'web-pool',
}

The instances have to be configured with the needed software and services. For this purpose create the following manifests:

We start with a simple Apache installation for the web nodes, having PHP with the MongoDB extension enabled, serving a simple PHP script that connects to our new MongoDB replica set and performs some basic actions.

# /etc/puppet/manifests/web.pp
#
# Web node
#
class web {

  package { "apache2-mpm-prefork":  
      ensure  => latest
  }
  
  package { "libapache2-mod-php5":  
      ensure  => latest, 
      notify  => Service["apache2"] 
  }

  service { "apache2":
      ensure     => "running",
      enable     => true,
      hasrestart => true,
      require    => Package["apache2-mpm-prefork", "libapache2-mod-php5"]
  }

  package { "php5-mongo":  ensure  => latest }
      
  file { "/var/www/index.php":
    ensure  => file,
    path    => '/var/www/index.php',
    owner   => "www-data",
    group   => "www-data",
    mode    => "0644",
    require => Package["apache2-mpm-prefork"],
    content => "setReadPreference( MongoClient::RP_PRIMARY_PREFERRED );

\$c = \$m->foo->bar;
\$c->insert( array( 'msg' => sprintf( 'Hello from %s at %s.', '${hostname}', date('Y-m-d H:i:s') ) ) );

echo 'Hi, this is ${hostname} on a load balanced apache and connected to a MongoDB replica set';
echo '
';
        
\$cursor = \$c->find();
foreach (\$cursor as \$doc) {
    var_dump(\$doc);
}

echo '
';

"
  }      
  file { "/var/www/index.html":
    ensure  => absent,
    owner   => "root",
    group   => "root",
    require => [ Package["apache2-mpm-prefork"], Service["apache2"] ]
  }

}

The manifest for our database adds some system tuning for the MongoDB service as suggested by the MongoDB Team, ensures the correctly mounted disk and defines the installation and configuration of the MongoDB server with a replica set.

# /etc/puppet/manifests/database.pp
#
# MongoDB node
#
#
class database (
  $replicaset             = 'replica',
  $replicaset_type        = 'member',
) {
  
  include stdlib

  #
  # System settings
  # Adapted from http://docs.mongodb.org/ecosystem/platforms/google-compute-engine/
  #
  # /etc/security/limits.conf
  file_line { 'limits.conf-soft-nofile':
    ensure => present,
    line   => 'mongod soft nofile 64000',
    path   => '/etc/security/limits.conf',
  }
    
  file_line { 'limits.conf-hard-nofile':
    ensure => present,
    line   => 'mongod hard nofile 64000',
    path   => '/etc/security/limits.conf',
  }
  
  file_line { 'limits.conf-soft-nproc':
    ensure => present,
    line   => 'mongod soft nproc 32000',
    path   => '/etc/security/limits.conf',
  }
    
  file_line { 'limits.conf-hard-nproc':
    ensure => present,
    line   => 'mongod hard nproc 32000',
    path   => '/etc/security/limits.conf',
  }
  
  # /etc/security/limits.d/90-nproc.conf
  file { '/etc/security/limits.d/90-nproc.conf':
    ensure => present
  }
  ->
  file_line { '90-nproc.conf-soft-noproc':
    line => 'mongod soft nproc 32000',
    path => '/etc/security/limits.d/90-nproc.conf',
  }
  ->
  file_line { '90-nproc.conf-hard-noproc':
    line => 'mongod hard nproc 32000',
    path => '/etc/security/limits.d/90-nproc.conf',
  }
  
  # /etc/sysctl.conf
  file_line { 'sysctl.conf-tcp_keepalive_time':
    line => 'net.ipv4.tcp_keepalive_time = 300',
    path => '/etc/sysctl.conf',
  }
  
  # /etc/udev/rules.d/85-mongod.rules
  exec { 'blockdev-setra':
    onlyif  => "/usr/bin/test ! -f /etc/udev/rules.d/85-mongod.rules",
    command => '/sbin/blockdev --setra 32 /dev/disk/by-id/google-mongodb',
    require => Mount["/var/lib/mongodb"]
  }
  ->
  file { '/etc/udev/rules.d/85-mongod.rules':
    ensure => present
  }
  ->
  file_line { '85-mongod.rules':
    line => 'ACTION=="add", KERNEL=="disk/by-id/google-mongodb", ATTR{bdi/read_ahead_kb}="32"',
    path => '/etc/udev/rules.d/85-mongod.rules',
  }

  #
  # User, group and directories  
  #
  group { "mongodb":
    ensure  => present,
  }
  ->
  user { "mongodb":
    ensure  => present,
    gid     => "mongodb",
    require => Group["mongodb"]
  }
  ->
  # The mongodb module has a File resource /var/lib/mongodb - so we have to do a mkdir
  exec { "mkdir-var-lib-mongodb":
    command     => "/bin/mkdir -p /var/lib/mongodb >/dev/null 2>&1",
    user        => "root", 
    unless      => "/usr/bin/test -d /var/lib/mongodb",
  }
  -> 
  mount {'/var/lib/mongodb':
    ensure  => mounted,
    atboot  => true,
    device  => '/dev/disk/by-id/google-mongodb',
    fstype  => 'ext4',
    options => 'defaults,auto,noatime,noexec'
  }
  ->
  exec { "/bin/chown -R mongodb /var/lib/mongodb":
    unless => "/bin/bash -c '[ $(/usr/bin/stat -c %U /var/lib/mongodb) == \"mongodb\" ]'",
  }
  exec { "/bin/chgrp -R mongodb /var/lib/mongodb":
    unless => "/bin/bash -c '[ $(/usr/bin/stat -c %G /var/lib/mongodb) == \"mongodb\" ]'",
  }
  ->
  class {'::mongodb::globals':
    manage_package_repo => true,
    bind_ip             => '0.0.0.0'
  }
  ->
  class {'::mongodb::server':
    ensure           => present,
    bind_ip          => '0.0.0.0',
    directoryperdb   => true,
    replset          => $replicaset,
    require          => Mount["/var/lib/mongodb"]
  }
  ->
  class {'::mongodb::client': }
  
  if $replicaset_type == 'primary' {
  
    mongodb_replset { $replicaset:
      ensure  => present,
      members => ['mongodb1:27017', 'mongodb2:27017', 'mongodb3:27017'],
      require => [ Mount["/var/lib/mongodb"], Class['mongodb::server'] ]
    }
      
  }

}

The site.pp is the main manifest with our node definitions.

# /etc/puppet/manifests/site.pp
#
# Site.pp
#
import "web.pp"
import "database.pp"
  
node /^web(1|2)$/ {
  include web
}
node 'mongodb1' {
  class { 'database':
    replicaset_type  => 'primary',
  }
}
node /^mongodb(2|3)$/ {
  include database
}

Next apply the cluster_up.pp manifest with
sudo puppet apply --certname my_project /etc/puppet/manifests/cluster_up.pp

The instances should be created and provisioned with the defined software and services within a few minutes. Just type the ip address of the created load balancer into your browser to check the status. You can retrieve the ip address in your Google Developer Console or by using gcutil:

sudo gcutil getforwardingrule web-rule

You should see a simple webpage served randomly from instance web1 and web2 inserting a simple log message to your just created MongoDB Replica Set.

Now that we have the highly avaliable LAMP cluster with MongoDB up and running, you can start with your own customizations on the Puppet Master. Just edit site.pp, web.pp or database.pp on the Master to fit your needs. An agent polls the master periodically every 30 minutes to retrieve and apply the current catalog.

The sources of all manifests can also be found on Github.

Further Information:
Using Puppet to Automate Google Compute Engine
Supporting documentation for Using Puppet with Google Compute Engine
Automate Google Compute Engine with Puppet
Compute Engine Management with Puppet, Chef, Salt, and Ansible]]> https://www.stetic.com/developer/google-compute-engine-puppet-lamp/feed/ 0 https://www.stetic.com/favicon.ico https://www.stetic.com/favicon.ico https://www.stetic.com/developer/liste-von-ruby-gems-auf-einen-anderen-server-uebertragen/ https://www.stetic.com/developer/liste-von-ruby-gems-auf-einen-anderen-server-uebertragen/#comments Mon, 22 Jul 2013 14:45:00 +0000 Linux Webentwicklung gems ruby rubygems server https://www.stetic.com/developer/liste-von-ruby-gems-auf-einen-anderen-server-uebertragen/ Weiterlesen

Wer viel mit Ruby und Ruby on Rails arbeitet, kommt an Rubygems nicht vorbei. Was PEAR und Pecl für PHP und CPAN für Perl ist, ist Rubygems für Ruby: ein Paketsystem zum Installieren und Verwalten von Ruby-Modulen (Software, Librarys und Bibliotheken). Da es in Ruby für fast alles eine Library gibt und man sich mit Hilfe einer solchen Library viel Arbeit ersparen kann, kommt mit der Zeit eine ganz schöne Liste von installierten GEM’s zusammen, die bei komplexen Anwendungen durchaus auch mal dreistellig werden kann. Möchte man die Anwendung oder gleich mehrere nun auf einen neuen oder anderen Server installieren, müsste man entweder per Rake oder Bundler die Abhängigkeiten jeder einzelnen Rails-Anwendung auflösen oder jedes GEM einzeln per Hand installieren. Letzteres fällt bei einer großen Anzahl von GEM’s jedoch flach und wäre zu viel Aufwand. Abhilfe schafft hier ein kleines Perl-Script, welches alle installierten Pakete inklusive aller Versionen durchgeht und pro Version eine Install-Anweisung ausgibt.

Folgendes Script auf dem alten Server unter dem Namen „listgems.pl“ erstellen:

#!/usr/bin/perl -w
 
# We're strict
use strict;
 
# Get list of installed gems
my @gems = qx(gem list);
chomp(@gems);
 
# Create commands
foreach my $gem (@gems)
{
    # Match gem and versions
    $gem =~ m/(\S+)\s\((.+)\)/i;
    # Gem name
    $gem = $1;
    # Save them into array  
    my @gem_versions = split(/,/, $2);
    # Print out commands
    foreach (@gem_versions)
    {
        # Remove all whitespaces
        $_ =~ s/^\s+//;
        print "gem install $gem --version=$_\n";
    }
}

Nach dem Ausführen sollte ungefähr folgende Ausgabe erscheinen:

user@box:~# perl listgems.pl
gem install actionmailer --version=2.3.5
gem install actionpack --version=2.3.5
gem install activerecord --version=2.3.5
gem install activeresource --version=2.3.5
gem install activesupport --version=2.3.5
gem install addressable --version=2.2.6
gem install cgi_multipart_eof_fix --version=2.5.0
gem install chardet --version=0.9.0
gem install crack --version=0.1.8
gem install daemons --version=1.1.4
gem install fastercsv --version=1.5.4
gem install fastthread --version=1.0.7
gem install gem_plugin --version=0.2.3
gem install gemcutter --version=0.7.0
gem install hashie --version=1.0.0
gem install hpricot --version=0.8.6
gem install httpclient --version=2.2.3
..
gem install ruby-hmac --version=0.4.0
gem install Ruby-MemCache --version=0.0.1
gem install simple_oauth --version=0.1.5
gem install soap4r --version=1.5.8
gem install zanox --version=0.2.7
gem install zip --version=2.0.2


Diese Liste nun auf dem neuen Server als Bash-Script speichern:

user@box:~# vi install_gems.sh


Jetzt einfach die auf dem alten Server generierte Liste per Copy und Paste einfügen und ausführen:

user@box:~# bash install_gems.sh
Fetching: activesupport-2.3.15.gem (100%)
Fetching: rack-1.1.6.gem (100%)
Fetching: actionpack-2.3.15.gem (100%)
Fetching: actionmailer-2.3.15.gem (100%)
Successfully installed activesupport-2.3.15
Successfully installed rack-1.1.6
Successfully installed actionpack-2.3.15
Successfully installed actionmailer-2.3.15
4 gems installed
Installing ri documentation for activesupport-2.3.15...
Installing ri documentation for rack-1.1.6...
Installing ri documentation for actionpack-2.3.15...
Installing ri documentation for actionmailer-2.3.15...
Installing RDoc documentation for activesupport-2.3.15...
Installing RDoc documentation for rack-1.1.6...
Installing RDoc documentation for actionpack-2.3.15...
Installing RDoc documentation for actionmailer-2.3.15...
..


Nun sollten alle auf dem alten Server vorhanden GEM’s auf dem neuen installiert werden.

Wer kein Perl zur Hand hat oder eine kürzere Variante sucht, der kann folgenden Einzeiler in Bash ausführen.

user@box:~# gem list|sed 's/(//'|sed 's/)//'|sed 's/,//'|awk '{print "gem install " $1 " --version=" $2}'


Aber Achtung! Hier werden keine Versionen berücksichtigt, sondern immmer nur die erste Version ausgegeben. Das Bash-Script sollte also nur verwendet werden, wenn pro Paket auch nur eine Version installiert ist.

Dies ist eine freie Übersetzung und überarbeitete Version des Original-Posts von Artur Krzywanski. Vielen Dank.

]]>

Placehold.it

Wie der Name schon verrät geht es hier um Platzhalter und zwar für Grafiken. Genial! Wie oft hat man sich beim Erstellen einer Webseite irgendein Foto genommen und verändert oder irgendwelche Fakebilder als Platzhalter für die späteren wirklichen Bilder verwendet. Das benötigt man nun nicht mehr, denn dank Placehold.it kannst du Platzhalter für die Bilder in jeder beliebigen Größe erstellen. Dazu kann das Format, die Farbe, der Text und natürlich wie schon erwähnt die Größe einfach über das Verändern des Bildpfades oder der GET-Parameter geändert werden. Danke für dieses tolle Tool!

Webseite: http://placehold.it/

getFavicon

Das nächste Tool hat mir wirklich schon oft geholfen und jede Menge Arbeit erspart. getFavicon ist eine Art Proxy für Favicons. Man kann sich hier von jeder Domain und von jedem Pfad in einer Domain das jeweilige Favicon anzeigen lassen. Hierzu übergibt man dem Tool einfach die URL der benötigten Domain inkl. Pfad und schon wird das Favicon angezeigt. Klasse für Listen mit Domains oder URL’s. Features wie SSL, Setzen des Default-Icons wenn keins gefunden wird, Decaching und einiges mehr machen das Tool wirklich brauchbar und sehr nützlich.

Webseite: https://getfavicon.appspot.com

Favicon.ico Generator

Jede kleine Webseite braucht die kleinen lustigen Grafiken, genannt Favicon. Das Favicon wird links neben der URL in der Adressleiste des Browsers angezeigt und für Bookmarks oder in anderen Diensten (wie z.B. über getFavicon, siehe oben) als grafische Beilage zur URL der Seite verwendet. Favicons zu erstellen war bisher immer ziemlich aufwendig. Man musste eine kleine Grafik, die maximal 32×32 Pixel groß war erstellen, als BMP speichern und mit einem gesonderten Programm als Icon exportieren. Favicon.cc vereinfacht diesen Prozess. In diesem Online-Tool kann man Favicons selbst pixeln und erstellen oder bestehende Bilder ganz einfach importieren und verändern. Das fertige Favicon kann natürlich heruntergeladen und auf Wunsch auf der Seite veröffentlicht werden. Sehr nützliches Tool!

Webseite: http://www.favicon.cc

Ultimate CSS Gradient Generator

CSS3 bietet wahnsinnig viele schöne neue Möglichkeiten. Eine davon sind Farbverläufe, die man in beliebiger Farbe, Richtung und Grösse einfach per CSS auf jedes HTML-Element anwenden kann. Da dies jeder Browser aber noch etwas anders implementiert, sind für einen Verlauf viele Zeilen CSS-Code zu schreiben. Händisch fast unmöglich. Genau hier springt der CSS Gradient Generator ein. Mit ihm kann man die benötigten Farben wählen oder direkt über Eingabe des Hexcodes definieren und über ein Photoshop-like Interface die Verläufe anpassen und verändern. Ist man mit dem Ergebnis in der Vorschau zufrieden, kann man sich direkt den generierten CSS-Code kopieren und in’s eigene Stylesheet einfügen. Super easy und hilfreich. Probiert es einfach mal aus, einfacher geht es nicht!

Webseite: http://www.colorzilla.com/gradient-editor/

TinyPNG

Die Ladezeit einer Webseite ist extrem wichtig. Wer möchte heutzutage noch gerne länger warten bis eine Webseite vollständig geladen ist. Ein entscheidender Faktor von vielen für schnellere Ladezeiten einer Webseite ist die Grösse von Bildern. TinyPNG ist eine Online-Tool, das die Grösse von PNG-Grafiken um einiges verkleinert. Einfach das gewünschte Bild oder mehrere (maximal 20 Bilder und 2 MB pro Bild) per Drag’n’Drop auf die dafür vorgesehene Fläche auf der TinyPNG-Webseite ziehen und schon beginnt der "Shrink"-Prozess begleitet von einer lustigen Panda-Animation. Nach Fertigstellung können die Bilder sofort heruntergeladen werden. Im Vergleich zu Photoshop verkleinert TinyPNG die Bilder um 40% und mehr – und das ohne optisch sichtbare Veränderung des Bildes. Klasse! Mehr ist hier nicht rauszuholen. Sehr hilfreich – speed up your website!

Webseite: http://tinypng.org

CSS3 Generator

Hier verrät der Name im Prinzip schon alles. Mit dem CSS3 Generator kann man über ein sehr einfaches Interface schnell CSS3-Code für Features wie Border-Radius, Box-Shadow, Font-Shadow, Verläufe, RGBA, @Font-Face und vieles mehr generieren. Leider fehlt im generierten Code die Angabe -moz für Gecko-basierte Browser wie Firefox oder Seamonkey, die man aber ohne weiteres per Hand ergänzen kann. Für schnelle Code-Generierung sehr hilfreich, das Tool sollte in keiner Tool-Sammlung und Linkliste von Webdesignern fehlen.

Webseite: http://css3generator.com

Color Scheme Designer

Wenn man sich bei der Erstellung einer Webseite, eines Logos oder sonstiger grafischer Ergüsse auf die Hauptfarbe(n) geeinigt hat, ist es oft ziemlich aufwendig und schwierig hierzu passende Farben zu finden, damit die Webseite oder die Grafik einen harmonischen und schönen Eindruck macht. Hier hilft der Color Scheme Designer weiter und findet schnell sehr gut Farben die zueinander passen und ermöglich so die Erstellung eines kompletten Farbschemas. Genial! Durch die Wahl der verschieden Modes Mono, Complement, Triad, Tetrad, Analogic und Accented Analogic sind unendlich viele Farb-Kombinationen auf gewünschter Basis möglich. Das Tool gibt es schon etwas länger, ist bei mir aber etwas in Vergessenheit geraten, was auf keinen Fall mehr passieren wird, da die Ergebnisse des Tools wirklich ziemlich brauchbar und umwerfend sind. Wer so etwas schon in Photoshop per Hand versucht hat und keine grafische Ausbildung genossen hat, wird dieses Tool umso mehr lieben. Just try it!

Webseite: http://colorschemedesigner.com

100 Random Colors

Hundert zufällige Farben. Genau das und nicht mehr macht dieses Tool und zeigt hundert zufällige Farben im Quadrat mit Hexcode der jeweiligen Farbe an. Ist keine Farbe dabei, für die man sich begeistern kann, lädt man die Seite neu und erhält die nächsten hundert zufälligen Farben. Tolle Idee und gut zu gebrauchen für die Ideenfindung und als Inspirationsgeber für Farben.

Webseite: http://www.100randomcolors.com

Color Hunter

Mit dem Farbjäger, dem Color Hunter, kann man passende Farben aus einem Bild oder zu einem Bild finden. Das Bild kann über die Angabe der URL oder über Upload hinzugefügt werden. Ganz nett, wenn man ein Bild hat und farblich hierauf eine Webseite oder passende Elemente aufbauen möchte. Das Tool liefert allerdings nicht immer zufrieden stellende Ergebnisse und bis auf die die Helligkeit gibt es keine Möglichkeit Einfluss auf das Ergebnis zu nehmen. Als Ideen- und Farbgeber aber dennoch sehr gut zu gebrauchen.

Webseite: http://www.colorhunter.com

ColorBlender

Das letzte Farbtool in dieser Liste, der ColorBlender, bietet als selbst ernannter Farbwerkzeugkasten ebenso die Möglichkeit Farbschemas oder Farbmischungen zu erstellen. Hierbei kann man an einem RGB oder HSV-Regler die gewünschte Ausgangsfarbe einstellen, anhand der die 6-farbige Platte bzw. Mischung errechnet wird. Die fertige Mischung kann gespeichert und später wieder verwendet werden. Hierfür benötigt man ein Benutzerkonto. Ohne Registrierung kann man das Ergebnis als Photoshop-Farbtabelle oder Illustrator-Farben (.EPS) downloaden oder per E-Mail verschicken. Zusätzlich kann man bereits erstellte Mischungen von anderen anschauen und verwenden. Sehr nützlich für ein Farben-Brainstorming oder komplette Konzeptionen. Ein klasse Tool!

Webseite: http://colorblender.com

Keyonary

Oft kann man Sie gebrauchen, oft vergisst man sie aber auch. Die Rede ist von Shortcuts. KEYONARY versteht sich als Shortcut-Finder und hilft einem in sehr schönem Design bei vergessenen Shortcuts auf die Sprünge. Natürlich kann man auch ganz neue noch unbekannte Screenshots entdecken oder hinzufügen. Shortcuts können per Volltextsuche oder per Auswahl des Betriebsystems oder der Anwendung gefunden werden. Die Idee, Umsetzung und das Design ist wirklich sehr gut gemacht und auf jeden Fall einen Besuch und Bookmark wert!

Webseite: http://keyonary.com/

Google Web Fonts

Zu diesem Tool muss man eigentlich nicht mehr viel sagen, dennoch muss es unbedingt auf meine Liste. Lange war es einem im Web verwehrt andere Schriftarten außer Arial, Verdana, Helvetica oder Times zu nutzen, weil es technisch nicht möglich oder nicht auf allen Browsern und Betriebssystemen lauffähig war. Seit Google Web Fonts kann man nun aus unzähligen Schriftarten wählen und über Einfügen des entsprechenden Javascripts die Schriftart auf der eigenen Webseite nutzen. Bis auf die 2% der Besucher, die Javascript deaktiviert haben, bei denen es sich meist sowieso um Bots handelt, kann diese Schriftart in allen Browsern angezeigt werden. Und das Beste: Alle dort angebotenen und nutzbaren Fonts sind Open Source und auch der Service und dessen Nutzung sind kostenlos. Wer sich jetzt noch um die Erreichbarkeit seiner Webseite Sorgen macht, weil ein externes Javascript eingebunden werden muss, dem sei gesagt, das Google Server so gut wie keine Ausfälle haben und zu den schnellsten und ausfallsichersten Servern im Web gehören. Unschlagbar gut und unverzichtbar. Danke Google!

Webseite: http://www.google.com/webfonts

Button Maker

Das wichtigste Action-Element auf Webseiten ist auf jeden Fall der Button. Er wird für fast alles wichtige benutzt, es wird wie wild auf Ihm herumgedrückt und er muss immer gut aussehen. Für letzteres gibt es den genialen Button Maker von CSS Tricks. Hier kann man schöne abgerundete Buttons mit Farbverläufen und Schatten erstellen. Über einen Regler kann man die Größe, das Padding und die Grösse der abgerundeten Ecken einstellen. In sieben Farbfeldern wählt man die gewünschten Farben für den Verlauf, die Hintergrundfarbe, Textfarbe, Rahmenfarbe, Hoverfarbe usw. Zum Schluß noch schnell die Schriftart gewählt und sobald man mit dem Ergebnis zufrieden ist, kann man mit einem Klick auf – na? – den fertigen Button (wo sonst?) den CSS-Code generieren lassen und in das eigene Stylesheet kopieren. Super easy zu benutzen und unbedingt zu empfehlen. Hammer Tool!

Webseite: http://css-tricks.com/examples/ButtonMaker/

CodeMirror

Wer einen Quelltext- oder Code-Editor auf seiner Webseite integrieren möchte, um das Bearbeiten von HTML, Javascript, PHP, Ruby oder anderen Sprachen zuzulassen, der kommt um den besten freien Javascript-Code-Editor mit Namen CodeMirror nicht herum. Dieser Editor bietet unendlich viele Möglichkeiten, wie Syntax-Highlighting für alle gängigen Sprachen, Shortcuts, Auto-Completion und viele weiteren Funktionen, die man von einer normalen IDE gewohnt ist. Durch die einfache API lässt sich das Tool wunderbar und unendlich mit eigenen Sachen oder bestehenden Addons erweitern. Das Tool muss heruntergeladen und durch Einbau des CSS und Javascripts in die eigene Webseite integriert werden, ist von daher zwar kein Online-Dienst, darf hier aber dennoch nicht fehlen wie ich finde. Einfach genial! Online Code Editing. Das schreit nach neuen webbasierten Editoren. Ich denke das wir hier noch einiges erwarten dürfen. Keep on coding!

Webseite: http://codemirror.net/

Pingdom Full Page Test / Page Speed Tool

Wie schon vorher erwähnt ist die Ladezeit einer Webseite sehr wichtig. Um die genaue Ladezeit einer Webseite zu ermitteln kann man entweder eines der zahlreichen Browser-Plugins, von denen das bekannteste Google Page Speed ist, nutzen oder auf ein Online-Tool wie den Full Page Test von Pingdom setzen. Meines Wissens nach setzt Pingdom hier auch auf die Messtechnik der Google Page Speed API, der Vorteil ist hier aber ganz klar das man den Test über eine Webseite machen kann. Einfach Webseite aufrufen, URL der zu testenden Seite eingeben und in (hoffentlich) wenigen Sekunden hat man das Ergebnis in Form von Zeit und Bytes für die komplette Seite und aller Elemente, die sich auf der Seite befinden. Die Anzeige des detailierten Performance-Grads und der ausführlichen Analyse-Tabellen runden das Tool ab. Hiermit kann man super Schwachstellen identifizieren, die meist durch wenige Handgriffe zu eliminieren sind.

Webseite: http://tools.pingdom.com/fpt/

Onedit CMS

Das 16. und letzte Tool dieser Liste ist eine Eigenentwicklung und läuft etwas ausser Konkurrenz, deshalb 15 +1 Tools. Es handelt sich um ein von mir entwickeltes Content-Management-System, kurz CMS. Solche Tools gibt es zwar schon wie Sand am Meer, das Besondere an diesem CMS ist aber, das man damit bestehende Webseiten bearbeiten kann, ohne eine Software auf dem Webspace oder dem eigenen Rechner zu installieren. Durch die Vergabe von CSS-Klassen kann man bestimmte Elemente einer Webseite zur Bearbeitung im CMS freigeben. In Onedit müssen nur noch die FTP-Zugangsdaten für den Webspace eingegeben werden (keine Angst, es wird alles verschlüsselt gespeichert) und schon kann das Bearbeiten der Webseite beginnen. Das CMS ist für Webdesigner besonders interessant, da man eigene Benutzer anlegen kann und Ihnen Zugriff auf bestimmte Webseiten, Unterseiten und Funktionen geben kann. Eine Whitelabel-Lösung mit eigenem Logo und eigener Domain ist ebenso möglich. Onedit ist in den Basis-Funktionen für eine Webseite und 10 Unterseiten kostenlos.
In Zukunft wird hier sicher noch ein kompletter Artikel über Onedit erscheinen, wenn die aktuellen Weiterentwicklungen des Tools abgeschlossen sind.

Webseite: http://www.onedit.de/

Ich hoffe es war für den einen oder anderen ein neues und hilfreiches Tool dabei. Ich nutze viele dieser Tools sehr oft. Vielleicht kennt Ihr auch noch andere Tools, die diese Liste super ergänzen würden? Freue mich über Kommentare.

Weiterführende Links für nützliche Tools:

• 50 nützliche Tools für Webentwickler bei t3n
• 50 New Resources and Tools for Web Developers bei Speckyboy
• 40 Useful Responsive Web Design Tools bei Tripwire
• 25 nützliche Tools für Webdesigner bei Dr. Web
• Nützliche Online-Tools für Webdesigner bei Designtrax
• 10 zeitsparende und kostenlose Tools für Webdesigner bei t3n

Bei den meisten Installationen unter Apache läuft PHP als Modul. Das heisst, für das Ausführen von PHP muß kein neuer Prozess gestartet werden, sondern die Verarbeitung bzw. Parsen der PHP-Dateien übernimmt das beim Start des Apachen geladene PHP-Modul. Für nginx gibt es solch ein Modul nicht, weshalb wir auf die CGI-Version von PHP zurückgreifen müssen. Dies ist nicht weiter tragisch, da die Performance – eine halbwegs schnelle CPU vorausgesetzt – aus Erfahrung nicht darunter leidet. Doch wie konfiguriert man nginx, um ihn für das Ausliefern von dynamischen PHP-Scripts vorzubereiten?

Installation von PHP5-CGI

Zuallererst benötigen wir nun die CGI-Version von PHP. Falls sie noch nicht installiert ist, können wir sie entweder selbst kompilieren oder verwenden von der Linux-Distribution bestehende Pakete. Für Ubuntu ist die Installation hier mit einer Zeile erledigt:

# apt-get install php5-cgi

Sofern man für WordPress zum Beispiel noch mehr Module wie MySQL oder GD benötigt, könnte die Zeile auch so aussehen:

# apt-get install php5-cgi php5-dev php5-gd php5-mysql

Die Verbindung zu nginx: Sockets für PHP

Damit wir PHP mit nginx nutzen können, benötigen wir sogenannte Sockets unter denen das PHP auf Anfragen von nginx wartet, wahlweisse als TCP- oder UNIX-Domain-Socket. Da ein Socket ständig auf neue Verbindungen wartet, muß ein neuer Prozess erzeugt werden, der diese Arbeit übernimmt. Dieser Prozess erzeugt weitere Unterprozesse und leitet die PHP-Anfragen dann an diese weiter.

Es gibt nun mehrere Möglichkeiten die PHP-Prozesse zu starten. Die Aufgabe ist hier, die Prozesse als Daemon und unter einem anderen User laufen zu lassen, sowie die Standard- und Fehler-Ausgaben umzuleiten.
Zwei Möglichkeiten möchte ich hier aufzeigen: Zum einen kann man die Prozesse ganz normal per Startscript starten, auf Ubuntu zum Beispiel mit dem start-stop-daemon. Zum anderen gibt es Tools wie spawn-fcgi, mit dem ich jedoch nicht so gute Erfahrungen gemacht habe, da es bei mir öfters, teilweisse sogar mit Segfaults, unter Last abstürzte. Da ich aber keine Zeit hatte, dem Grund auf die Spur zu gehen und PHP mit dem start-stop-daemon bei mir ziemlich gut läuft, möchte ich euch spawn-fcgi der Vollständigkeithalber nicht vorenthalten. Sicher auch hilfreich für andere Linux-Distributionen.

PHP im FASTCGI-Modus mit Startscript

Die in PHP mitgelieferte CGI-Version php5-cgi erledigt im FastCGI-Modus die Socketbindung und das Erzeugen von neuen Prozessen selbstständig und sehr zuverlässig. Zum Starten benötigen wir ein Startscript, welches wir unter /etc/init.d/fastcgi anlegen:

# vi /etc/init.d/fastcgi

Inhalt:

#!/bin/bash
BIND=127.0.0.1:8088
USER=www
PHP_FCGI_CHILDREN=15
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php5-cgi

PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
    echo -n "Starting PHP FastCGI: "
    start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}
stop() {
    echo -n "Stopping PHP FastCGI: "
    killall -q -w -u $USER $PHP_CGI
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}

case "$1" in
   start)
    start
;;
   stop)
    stop
;;
   restart)
    stop
    start
;;
   *)
    echo "Usage: php-fastcgi {start|stop|restart}"
    exit 1
;;
esac
exit $RETVAL


Die ersten fünf Variablen werden zur Konfiguration benötigt und bedeuten folgendes:

BIND: IP-Adresse und Port, unter denen auf Verbindungen gewartet wird
USER: Benutzer, unter dem die Prozesse laufen
PHP_FCGI_CHILDREN: Anzahl der zu forkenden bzw. erstellenden Prozesse
PHP_FCGI_MAX_REQUESTS: Anzahl von Requests, nach denen der Prozess stirbt (neue werden automatisch erstellt)
PHP_CGI: Pfad zu php5-cgi

Evtl. muß nun noch der Pfad zu php5-cgi und der Benutzer angepasst werden und wir können das Script nach einem chmod ausführen:

# chmod 700 /etc/init.d/fastcgi
# /etc/init.d/fastcgi start


Mit dem Befehl „ps ax“ sollten wir nun in der Prozessliste unsere PHP-Prozesse laufen sehen und gehen jetzt zur nginx-Konfiguration über.

Fast-CGI mit spawn-fcgi

spawn-fcgi macht eigentlich auch nichts anderes als das Startscript unter Ubuntu. Es erstellt einen TCP/Unix-Domain-Socket und die gewünschte Anzahl von Prozessen unter einem bestimmten Benutzer und leitet die Ausgaben ensprechend um. Zur Installation benötigen wir natürlich die aktuellen Sourcen von spawn-fcgi, deren Link wir auf der News-Seite des Projektes erhalten. Download, Entpacken und ins Verzeichnis wechseln:

# wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
# tar -xvzf spawn-fcgi-1.6.3.tar.gz
# cd spawn-fcgi-1.6.3


Nun folgt das bekannte Zweiergespann zum Kompilieren. spawn-fcgi besitzt keine Install-Routine, weshalb wir dies selbst vornehmen müssen:

# ./configure
# make
# cp ./src/spawn-fcgi /usr/bin/spawn-fcgi


Nun können wir das Tool das erste mal starten.

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 8088 -F 3 -u www -f /usr/bin/php5-cgi

Die Bedeutung der Optionen:

-a    IP-Adresse, an der auf Verbindungen gewartet wird
-p    Port, an dem auf Verbindungen gewartet wird
-w    User unter dem die Prozesse laufen sollen
-f    Pfad zum PHP-CGI
-F    Anzahl der Prozesse, die geforkt werden sollen

Konfiguration des nginx für PHP mit Fast-CGI

Wenn wir bereits einen fertigen nginx am Laufen haben, sind nur wenige Zeilen in der Konfiguration zu ergänzen. Ansonsten lies bitte zuerst meine Anleitung zur Installation und Konfiguration des nginx.

Innerhalb des Vhosts, also innerhalb von server {} fügen wir eine neue Location-Direktive für PHP-Files hinzu:

   location ~ .*\.php$ {
    root /var/www/meinedomain.de/htdocs;
    fastcgi_pass 127.0.0.1:8088;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
   }


Hier darauf achten, das die Angaben in fastcgi_pass mit denen der vorhin konfigurierten übereinstimmen. include fastcgi_params inkludiert eine Datei, die bei der nginx-Installation enthalten ist, möchte Sie hier jedoch abbilden für den Fall das…

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;


Damit nginx auch beim Aufruf der Domain ohne Dateiname in der URL die Startseite als PHP ausführt, müssen wir zwei Parts in der bestehenden Konfiguration unter server {} anpassen bzw neu einsetzen:

Als erstes machen wir die Datei index.php zur ersten Wahl beim Aufruf ohne Dateiname:

index index.php index.html index.htm;


Alles andere was nicht gefunden wird, leiten wir ebenfalls auf index.php weiter:

# this sends all non-existing file or directory requests to index.php
if (!-e $request_filename) {
rewrite . /index.php last;
}


Das komplett Konfigfile könnte nun so aussehen:

server {
        # IP-Adresse und Port, an denen für Web-Zugriffe gelauscht wird
        listen     1.2.3.4:80;

        # Domains, auf die dieser Server hören soll
        server_name www.meinedomain.de meinedomain.de;

        # Hauptverzeichnis für Dokumente
        root         /var/www/meinedomain.de/htdocs;

        # Ort des Access-Logfiles
        access_log /var/www/meinedomain.de/logs/access_log vhosts;

        # Definition des Index-Files (Startseite, für Anfragen ohne Dateiname)
        index index.php index.html index.htm;;

        # Wenn Zugriff auf andere als Standarddomain,
        # auf diese per 301 permanent weiterleiten
        if ($host != 'www.meinedomain.de' ) {
         rewrite ^/(.*)$ http://www.meinedomain.de/$1 permanent;
        }

        # Für Bilder und einige andere Dateitypen Access-Log ausschalten und
        # Expire-Zeit auf 7 Tage erhöhen (sendet den entspr. Expire-Header)
        location ~* ^.+\.(js|css|jpg|jpeg|gif|png|pdf|zip|rar)$ {
         access_log off;
         expires     7d;
        }

        location / {
         # Nützlich für SSL und evtl. später hinzukommende Scriptsprachen
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_redirect off;

         # Wenn die angeforderete statische Datei existiert, diese ausliefern
         # ohne die anderen Regeln weiter unten zu beachten
         if (-f $request_filename) {
            break;
         }

         # this sends all non-existing file or directory requests to index.php
         if (!-e $request_filename) {
            rewrite . /index.php last;
         }
        }

        location ~ .*.php$ {
         root /var/www/meinedomain.de/htdocs;
         fastcgi_pass 127.0.0.1:8088;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
         }
}


Jetzt heißt es den nginx mit /etc/init.d/nginx restart neu starten und PHP ist einsatzbereit.

WordPress kann nun ganz normal installiert und verwendet werden.

Insofern man ein Cache-Modul wie WP-Super-Cache nutzt, sollte man noch die entsprechenden RewriteRules für die statischen HTML-Dateien setzen. Für WP-Super-Cache beispielsweisse einfach folgende Zeilen innerhalb location / {} und vor der Einstellung für die .php-Dateien kopieren:

if (-f $document_root/cache$fastcgi_script_name) {
rewrite (.*) /cache$1 break;
}
if (-f $document_root/cache/$fastcgi_script_name/index.html) {
rewrite (.*) /cache/$1/index.html break;
}
if (-f $document_root/cache$fastcgi_script_name.html) {
rewrite (.*) /cache$1.html break;
}


Geschafft! Jetzt haben wir nginx mit PHP laufen und können uns über die bessere Performance freuen. Wenn du noch weitere Beispiele für Konfigurationen, auch für andere Sprachen und Einsatzmöglichkeiten suchst, empfiehlt sich ein Blick auf die Configuration-Seite von nginx.

Sicher folgen noch einige Artikel mehr über den nginx, um meine Begeisterung kund zu tun ;-) Solltest Du also Fragen, Wünsche, Vorschläge oder sonstiges haben, ab damit in die Kommentare, ich freue mich!

Credits:

Original-Foto Strap-On Video Rocket unter Creative Commons von jurvetson auf Flickr. Danke!

Marktanteile Top-Server über alle Domains Aug. 1995 – Feb. 2011. Quelle: netcraft.com

Seine weite Verbreitung, immerhin ist der Apache fast bei jedem Betriebssystem außer Windows dabei, die Anzahl der erhältlichen Erweiterungen und Module und die relativ leichte Konfiguration, auch in Massenhosting-Umgebungen, machen den Apache auch für Einsteiger zu einem Webserver der ersten Wahl. Wer jedoch mit viel Traffic zu tun hat und dabei eine serverseitige Skriptsprache wie PHP, Perl, Ruby oder ähnliches einsetzt, wird mit dem Apachen früher oder später an seine Grenzen stossen. Es ist mit Hilfe von Reduzierung auf wesentliche Module, Performance-Tuning und Tuning des Linux Systems natürlich sehr viel raus zu holen, doch irgendwann steht die Frage nach einer Alternative im Raum.

Der Webserver nginx

Hier war bis vor wenigen Jahren gerade im Linux-Bereich der Webserver lighttpd auf dem Weg eine echte Alternative zu werden, wurde jedoch im Jahr 2008 sehr schnell von einem Webserver Namens nginx überholt. nginx hat aktuell eine Verbreitung von 7.57% auf 21,570,463 Hosts. Tendenz stark steigend.
Der von Igor Sysoev ursprünglich für die russische Suchmaschine Rambler entwickelte nginx-Webserver, der auch als Reverse Proxy und E-Mail-Proxy verwendet werden kann, zeichnet sich durch seine hohe Performance und leichte Konfiguration aus. Gerade in Sachen Performance hat er den Apache schon einige Male in die Ecke verwiesen. nginx wird auch bereits von vielen High-Traffic-Seiten wie beispielsweise Golem.de, WordPress.com, t3n.de, GitHub und vielen weiteren mehr eingesetzt. Auch als zusätzliche Software zum Beispiel als Load-Balancer, Proxy, SSL-Proxy oder für das Ausliefern von reinen statischen Inhalten wie Grafiken, Stylesheets oder Videos eignet sich nginx durch seine kurzen Responce-Zeiten sehr gut.

nginx: Die Installation

Die Software zu installieren ist im Prinzip nicht weiter schwierig, sofern man Linux-Grundkenntnisse mitbringt. Download, Configure, Make, Install, Konfigurationsfiles anpassen und fertig ist die nginx-Installation. Doch eins nach dem anderen und auch für Einsteiger etwas langsamer erklärt. Ich möchte hier an einem Beispiel aufzeigen, wie man den nginx-Webserver installiert, konfiguriert und für das Ausliefern von statischen Webseiten vorbereitet.

Download des nginx

Die aktuelle stabile Version erhalten wir auf der Webseite des nginx. Aktuell ist die Version 0.8.54 vom 14.12.2010, die man unter folgenden URL downloaden kann:
http://nginx.org/download/nginx-0.8.54.tar.gz
Mit Linux macht man das am besten mit wget:

# wget http://nginx.org/download/nginx-0.8.54.tar.gz


Jetzt muß man den Tarball nur noch entpacken und es kann zur Installation übergehen.

# tar -xvzf nginx-0.8.54.tar.gz


Installation des nginx

Jetzt wechseln wir in das entpackte Verzeichnis. Um den nginx mit Standard-Modulen zu installieren reicht ein einfaches configure aus.

# cd nginx-0.8.54
# ./configure


Dies bereitet die Kompilierung des nginx in das Verzeichnis /usr/local/nginx mit Standard-Modulen wie dem HTTP-Kernmodul, HTTP-Upstreammodul, HTTP-Zugriffsmodul, HTTP-Authentifizierungsmodul und Fastcgi-Modul vor. Die Ausgabe der Zusammenfassung sollte so oder so ähnlich aussehen:

Configuration summary
+ using system PCRE library
+ OpenSSL library is not used
+ md5: using system crypto library
+ sha1 library is not used
+ using system zlib library

nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/local/nginx/sbin/nginx"
nginx configuration prefix: "/usr/local/nginx/conf"
nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
nginx pid file: "/usr/local/nginx/logs/nginx.pid"
nginx error log file: "/usr/local/nginx/logs/error.log"
nginx http access log file: "/usr/local/nginx/logs/access.log"
nginx http client request body temporary files: "client_body_temp"
nginx http proxy temporary files: "proxy_temp"
nginx http fastcgi temporary files: "fastcgi_temp"
nginx http uwsgi temporary files: "uwsgi_temp"
nginx http scgi temporary files: "scgi_temp"


Im nächsten Schritt heisst es kompilieren und installieren:

# make
# make install


Sollten diese beiden Make-Befehle ohne Fehler ausgeführt werden ist nginx nun unter dem Verzeichnis /usr/local/nginx installiert.

nginx: Die Konfiguration

Beginnen wir nun mit der Konfiguration. Im Prinzip können die Standard-Einstellungen übernommen werden, da sie für das Ausliefern von statischen Webseiten völlig ausreichend sind. Dennoch möchten wir hier einige Einstellungen variieren und jeweils noch die gewünschten Server bzw. Domains anlegen. Die Konfiguration befindet sich in der Datei /usr/local/nginx/conf/nginx.conf, die wir mit dem Editor unserer Wahl, in meine Fall der vi-Editor, öffnen:

# vi /usr/local/nginx/conf/nginx.conf

Globale Server-Einstellungen

An erster Stelle finden wir die globalen Einstellungen. Hier können Werte definiert werden, die für den gesamten Server gelten. Dazu gehören der User und die Gruppe unter der die Server-Prozesse laufen, Logfiles, Pidfile und Angaben zu Prozessen und MaxClients.

# User und Gruppe unter der der nginx läuft
user www www;

# Anzahl der Worker-Prozesse
worker_processes 2;

# Anzahl der maximalen Worker-Connections
events {
worker_connections 512;
}

# Ort und LogLevel der ErrorLog-Datei
error_log logs/error.log notice;

# Ort des Pidfiles
pid logs/nginx.pid;


Standardmässig läuft der nginx unter dem User nobody, was wir je nach Belieben anpassen können. Allerdings sollte man einen Werbserver niemals unter dem Benutzer root laufen lassen, um eventuellen Sicherheitslücken vorzubeugen.

Die Anzahl der Worker-Prozesse gibt an, wieviele Prozesse gestartet werden sollen. Der nginx startet einen Master-Prozess, der die Verwaltung übernimmt und die in der Konfiguration angegebene Anzahl von Worker-Prozessen. Diese Worker-Prozesse sind für die Verbindungen zum Benutzer und das Ausliefern der Webseite zuständig. 2 Worker-Prozesse sollten für den Anfang ausreichend sein.

Die Anzahl der Worker-Connections bestimmt die maximale Anzahl von gleichzeitigen Verbindungen, die ein Worker-Prozess verarbeiten kann. Aus beiden Werten von worker_processes und worker_connections ergibt sich hier also die maximale Anzahl von gleichzeitigen Verbindungen für den gesamten Webserver, der so genannten auch aus der Apache-Konfiguration bekannten Variable MaxClients. Die Formel hierfür ist

max_clients = worker_processes * worker_connections

In unserem Fall 2 * 512 = 1024. 1024 Verbindungen sollten für den Anfang mehr als ausreichend sein und können bei Ressourcenmangel ruhig auch bis 250 minimiert werden.

Den Ort und LogLevel der ErrorLog-Datei, sowie den Ort des Pidfiles können wir getrost so übernehmen.

HTTP Server-Einstellungen

Jetzt kommen wir zur Konfiguration des HTTP-Services und der einzelnen Server. Die Standard-Einstellungen sollten angepasst werden und wurden von mir für optimale und performante Auslieferung mit Hilfe von Gzip, Cache-Einstellungen usw. optimiert. Nehmen wir als Beispiel die IP 1.2.3.4 und eine Domain Namens www.meinedomain.de mit statischen HTML-Seiten, Bildern, Stylesheets und einigen Download-Dateien im Verzeichnis /var/www/meinedomain.de/htdocs, welches natürlich vorhanden sein sollte. Auch an SEO sollten wir gleich denken, die Domain wirklich nur unter einer Domain erreichbar machen und alles andere auf diese per 301-Weiterleitung weiterleiten.

http {
    # die Konfiguration der Content-Typen aus conf/mime.types inkludieren
    include     mime.types;

    # Der Standard-Content-Typ
    default_type application/octet-stream;

    # Support für größere Dateien
    sendfile     on;

    # HTTP Response-Header in einem Paket senden
    tcp_nopush     on;

    # Sekunden, in denen auf eine erneute Verbindung vom
    # gleichen Client gewartet wird
    keepalive_timeout 65;

    # Disable Nagle's buffer algorithm
    tcp_nodelay        on;

    # Gzip aktivieren, sendet komprimierte Daten zum Client
    gzip on;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_types     text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Definition des Logfile-Formats
    log_format vhosts '$http_host $remote_addr - $remote_user [$time_local] '
                             '"$request" $status $body_bytes_sent '
                             '"$http_referer" "$http_user_agent"';

# VHost-Konfiguration
server {
        # IP-Adresse und Port, an denen für Web-Zugriffe gelauscht wird
        listen     1.2.3.4:80;

        # Domains, auf die dieser Server hören soll
        server_name www.meinedomain.de meinedomain.de;

        # Hauptverzeichnis für Dokumente
        root         /var/www/meinedomain.de/htdocs;

        # Ort des Access-Logfiles
        access_log /var/www/meinedomain.de/logs/access_log vhosts;

        # Definition des Index-Files (Startseite, für Anfragen ohne Dateiname)
        index index.html;

        # Wenn Zugriff auf andere als Standarddomain,
        # auf diese per 301 permanent weiterleiten
        if ($host != 'www.meinedomain.de' ) {
         rewrite ^/(.*)$ http://www.meinedomain.de/$1 permanent;
        }

        # Für Bilder und einige andere Dateitypen Access-Log ausschalten und
        # Expire-Zeit auf 7 Tage erhöhen (sendet den entspr. Expire-Header)
        location ~* ^.+\.(js|css|jpg|jpeg|gif|png|pdf|zip|rar)$ {
         access_log off;
         expires     7d;
        }

        location / {
         # Nützlich für SSL und evtl. später hinzukommende Scriptsprachen
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_redirect off;

         # Wenn die angeforderete statische Datei existiert, diese ausliefern
         # ohne die anderen Regeln weiter unten zu beachten
         if (-f $request_filename) {
            break;
         }

         # index.html für Unterverzeichnisse
         if (-f $request_filename/index.html) {
            rewrite (.*) $1/index.html break;
         }
        }
}
}


Die Konfiguration besteht aus dem Part http mit Definitionen für diesen Service. Hier wird zuerst die Mime-Konfiuration geladen, Einstellungen zum Connection-Verhalten gesetzt, das Gzip-Modul zum komprimieren der Daten aktiviert und die Definition des Logfile-Formates vorgenommen. Weiter finden wir innerhalb des http-Parts den server-Part, die Konfiguration der einzelnen Websites, auch genannt VHosts. Ich habe auch hier die einzelnen Direktiven oben kommentiert, weshalb ich auf weitere detailiertere Beschreibung verzichte. Im Prinzip ist alles selbsterklärend. Will man weitere Domains bzw. Server hinzufügen muß man lediglich den Part server {} kopieren. Dabei ist darauf zu achten, daß jede Konfiguration nacheinander innerhalb von http {} steht. Ab zwei Servern lohnt es sich schon, für jeden Server ein eigenes Konfigurationsfile anzulegen. Hierfür erstellt man innerhalb des conf-Verzeichnisses ein Unterverzeichnis, zum Beispiel „sites“ und inkludiert die darin enthaltenen Files einfach innerhalb des http-Parts:

include /usr/local/nginx/conf/sites/*;


Jetzt kann man sich für jede Domain ein eigenes Konfigurationsfile anlegen, was wesentlich übersichtlicher ist.

Das nginx Startscript

Was uns jetzt noch fehlt ist, den nginx das erste Mal zu starten. Hierfür benötigen wir ein sogenanntes Startskript, welches wir z.B. hier für Ubuntu bekommen und unter /etc/init.d/nginx ablegen. Alternativ kann es hier kopiert und für evtl. andere Distributionen angepasst werden:

#!/bin/sh

#This is a start script for nginx. Tested on Unbuntu Edge.
#Should work on Ubuntu, Debian and probably a few other Linux distros.
#Change DAEMON and CONFIG_FILE if neccessary

PATH=/sbin:/bin:/usr/sbin:/usr/bin

#Location of nginx binary. Change path as neccessary
DAEMON=/usr/local/nginx/sbin/nginx
#Location of configuration file. Change path as neccessary
CONFIG_FILE=/usr/local/nginx/conf/nginx.conf

DAEMON_OPTS="-c $CONFIG_FILE"
NAME=nginx
DESC="web server"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

#only run if binary can be found
test -x $DAEMON || exit 0

set -e

#import init-functions
. /lib/lsb/init-functions

case "$1" in
start)
log_daemon_msg "Starting $DESC" $NAME
if ! start-stop-daemon --start --quiet\
--pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
log_end_msg 1
else
log_end_msg 0
fi
;;
stop)
log_daemon_msg "Stopping $DESC" $NAME
if start-stop-daemon --quiet --stop --oknodo --retry 30\
--pidfile $PIDFILE --exec $DAEMON; then
rm -f $PIDFILE
log_end_msg 0
else
log_end_msg 1
fi
;;
reload)
log_daemon_msg "Reloading $DESC configuration" $NAME
if start-stop-daemon --stop --signal 2 --oknodo --retry 30\
--quiet --pidfile $PIDFILE --exec $DAEMON; then
if start-stop-daemon --start --quiet \
--pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
log_end_msg 0
else
log_end_msg 1
fi
else
log_end_msg 1
fi
;;
restart|force-reload)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac

exit 0


Jetzt noch mit chmod das Ausführen der Datei erlauben:

# chmod 700 /etc/init.d/nginx

Nun können wir uns freuen und den nginx das erste Mal starten:

# /etc/init.d/nginx start

Ist alles korrekt und das Konfigurationsfile ohne Fehler, sollte der nginx starten und die Webseite unter der konfigurierten Domain erreichbar sein.

nginx Autostart

Damit der nginx auch beim nächsten Server-Neustart automatisch startet, benötigen wir einen Eintrag bzw. einen symbolischen Link im Runlevel-Startverzeichnis, hier als Beispiel für Ubuntu:

ln -s /etc/init.d/nginx /etc/rc2.d/S99nginx

Somit startet nginx beim nächsten Neustart des Servers im Runlevel 2 automatisch. Falls ein anderes Runlevel läuft (ersichtlich mit dem Befehl „runlevel“), einfach den Link im jeweiligen Verzeichnis erstellen.

Und nun: Viel Spaß mit nginx!

Das wars! Ich hoffe ich konnte Dir hier einen kleinen Einstieg in nginx vermitteln. Ein Artikel zur Verwendung von PHP und Installation von WordPress folgt demnächst. Bei Fragen, Verbesserungen oder Angregungen freue ich mich über Kommentare.

Weiterführende Links

– nginx-Webseite
– nginx-Wiki
– nginx bei Wikipedia
– nginx bei Ubuntu

1. Ubuntu Netbook Edition downloaden
http://www.ubuntu.com/netbook/get-ubuntu/download

Das war’s schon. Ansich wirklich kein Thema, wenn man sowas noch nie gemacht hat, ist so eine Kurzanleitung sicher ganz hilfreich.

Da die Funktions-Tasten (Screen-Beleuchtung, Lautstärke etc.) von Anfang an bei Ubuntu nicht funktionieren, hat mir diese Anleitung geholfen sie in Gang zu bekommen.

Viel Spaß!

1. .html on PAGES

Ich finde wichtig, das man alle Dateiendungen – sofern man welche nutzt – auf einer Webseite einheitlich hat. Da ich bei Posts die Endung .html bevorzuge, sollten auch die Seiten diese Endung haben dürfen. Man sagt es sei auch wichtig für Google.

2. All in One SEO Pack

Das ultimative SEO-Plugin. Hier kann man eigentlich alles einstellen, was man an SEO benötigt. Es gibt sicher einige andere oder bessere, hab mich aber auf dieses eingeschossen.

3. Antispam Bee

Verhindert Spam in Kommentaren und Pings sehr zuverlässig. Ziehe ich Askimet unbedingt vor, da es dem deutsche Datenschutz gerecht wird (falls das möglich ist:) und man hier keinen API-Key benötigt und es genauso gut wenn nicht besser läuft als Askimett.

4. Delete-Revision

WordPress legt bei jedem Speichern eine Version das Posts an, d.h. pro Speichern ein Datensatz in der Datenbank. Das wird natürlich bei vielen Artikeln auch ohne akutem Zucken auf den Speichern-Button eine Menge an Daten, die später so nicht mehr benötigt werden. Das Löschen der nicht benötigten Versionen bzw. Revisionen erledigt dieses Müllschlucker-Plugin „Delete-Revision“ zuverlässig. Yamyam!

5. Permalink Redirect

Noch ein SEO-Plugin. Entfernt alle unnötigen GET-Parameter bzw. Attribute und URL-Parts (the whole Crap!) von der URL und leitet auf die eigentliche URL weiter. Verhindert Duplicate Content. Wichtig für Google und SEO, also ein Muss.

6. Permalinks Moved Permanently

Ändert man mal den Permalink, also die URL eines Posts, muß die alte natürlich auf die neue weitergelietet werden. Das erledigt dieses nette Plugin.

7. Robots Meta

Ermöglicht pro Artikel oder Seite die Einstellung des Robots-Meta-Tag’s. Hiermit lässt sich bestimmen, welche Seiten oder Artikel im Google-Index indexiert werden sollen und wo Links verfolgt werden dürfen. Sehr nützlich für den SEO-Steuermann.

8. SEO Friendly Images

Fügt automatische Alt- und Title-Attribute zu Bildern hinzu. Genial, wenn man mit Bildern in Google gefunden werden will. Spart ’ne Menge Arbeit.

9. WordPress Database Backup

Hier kann man sich das Backup der WP-Datenbank in einem bestimmten Interval, beispielsweisse täglich, per Mail zusenden lassen, auf einem Rechner oder in einem Verzeichnis speichern lassen. Security first!

10. WP Super Cache

Cached alle Inhalte als statische HTML-Seiten, was die Ladezeit um einiges veringert. Dauer und Regeln lassen sich beliebig anpassen.

11. Yet Another Related Posts Plugin

Verlinkt passende Artikel untereinander. Klasse Plugin und Algorithmus! Bringt nicht nur dem benutzer viel Komfort, sondern auch Google und SEO.

Das ist sie also, meine Liste der Plugins die ich aktuell und aus den letzten 6 Jahren Erfahrung am wichtigsten erachte.

Nein, ein Plugin zur Integration von Twitter oder Facebook hab ich nicht, das hab ich bisher lieber selbst gemacht, da die meissten das Design zerschossen haben und das Fixing zu aufwendig gewesen wäre oder mir eben benötigte Features fehlten. Vielleicht findet sich aber noch ein brauchbares.

Wie sieht es bei euch aus, was habt Ihr unter der Haube? Oder haltet Ihr das ein oder andere Plugin für Käse?

Was aber, wenn wir dynamische Inhalte – beispielsweisse Texte aus einer Datenbank – verwenden und vorher gar nicht wissen, wieviel Inhalt jedes einzelne Element enthält? Durch den unterschiedlich langen Inhalt werden die Elemente jeweils auch unterschiedlich hoch dargestellt, was in den meisten Fällen unschön aussieht.

Hier kann das Javascript-Framework jQuery helfen. jQuery bietet eine Funktion mit dem Namen .height(), die uns die Höhe eines Elements setzen oder auslesen kann. Hier wird nicht einfach die CSS-Eigenschaft height ausgelesen, sondern die fertig gerenderte Höhe des Elements. So braucht man mit jQuery nicht viel Mühe, um alle gewünschten Elemente zu durchlaufen, das höchste zu bestimmen und alle Elemente auf eben diese Höhe anzupassen.

Der HTML-Code

Gehen wir von folgendem HTML-Code aus. CSS habe ich zur besseren Ansicht inline definiert:

  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.


  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.
  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.
  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.


  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.
  Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum Testen schreib ich hier irgendwas rein.

Das Javascript mit jQuery

Zuerst müssen wir die Höhe des höchsten Div’s ausfindig machen, indem wir alle Elemente durchlaufen. Dazu müssen wir uns den höchsten Wert einfach nur merken und immer vergleichen:

/* Variable zum Merken der maximalen Höhe */
var max_height = 0;

/* alle Elemente mit der CSS-Klasse "autoheight" durchlaufen */
$('.autoheight').each(function(e) {

  /* Höhe des aktuellen Elements */
  h = $(this).height();

  /* Wenn Höhe erfolgreich bestimmt werden konnte */
  if(typeof(h) != "undefined") {

        /* Wenn aktuelle Höhe gösser unserer maximalen, Höhe merken */
        if(h > max_height) {
                max_height = h;
        }
  }
});

Nun müssen wir die Höhe aller Elemente auf den gefundenen Wert setzen:

if(max_height > 0) {
 $('.autoheight').height(max_height);
}

Das ganze Javascript sieht dann so aus:

var max_height = 0;
$('.autoheight').each(function(e) {
  h = $(this).height();
  if(typeof(h) != "undefined") {
        if(h > max_height) {
                max_height = h;
        }
  }
});
if(max_height > 0) {
 $('.autoheight').height(max_height);
}

Das fertige Ergebnis als Beispiel

Das oben beschriebene Beispiel sollte dann in etwa so aussehen:

Boxen original

require 'net/http'

def check_for_notfound(url)
  uri = URI.parse(url)
  response = Net::HTTP.get_response(uri)

  case response
    when Net::HTTPNotFound:
      return true
    when Net::HTTPRedirection:
      puts check_for_notfound('http://' + uri.host + response['location'])
    else
      return nil
  end
end

File.open(ARGV[0]) do |f|
  f.each do |line|
    result = check_for_notfound(line)
    if !result.nil? and result == true
     puts line
    end
  end
end

Wer ein besseres Script hat oder etwa eine Möglichkeit weiß, wie man dies mit wget lösen kann, bitte einen Kommentar hinterlassen. Danke!

Update:

Wie ich Dank eines anderen Blogs erfahren konnte, ist das mit wget natürlich auch schnell und sogar mit einem Einzeiler lösbar:

wget -r -nd --delete-after --no-parent --no-cookies --input-file=urls.txt

Ob man nun Ruby oder wget nutzt, hängt ganz davon ab, ob man es in eine Software integrieren möchte oder ob es nur einem schnellen administrativen Todo dienen soll.

Schnell merkt man das die Größe der Festplatte nicht mehr ausreicht und der freie Speicherplatz wird immer geringer. Was also tun? Zum Glück kann man ein Loop Device problemlos vergrössern. Die folgende Anleitung beschreibt, wie man auf Linux-Systemen ein solches Loop Disk Image vergrössern kann, sofern man das ext2 oder ext3 Filesystem nutzt (Unter ext4 sollte dies ebenso laufen, wurde allerdings noch nicht getestet).

1. Virtuellen Server stoppen, der das zu vergrößernde Loop Device nutzt

2. Falls genügend Platz vorhanden ist, Backup des aktuellen Loop Devices erstellen mit:

# cp loop_image_file loop_image_file.backup

3. Folgenden Befehl zum Vergrössern des Loop Devices bzw. der Loop Disk Image nutzen:

# dd if=/dev/zero bs=1024k count=1024 >> loop_image_file

Anstatt „loop_image_file“ den Pfad zu Eurem Loop Disk Image nutzen. der Befehl fügt dem Image 1 GB Platz hinzu. Möchte man mehr Platz hinzufügen, ändert man einfach den count-Paremeter entsprechend des gewünschten Platzes. Unbedingt sicher gehen, das der zweifache (also hinzufügende) Redirector >> genutzt wird und nicht der einfache >. Sonst würde das File einfach überschrieben werden (deshalb auch zur Sicherheit unser Backup :-).

4. Plattencheck auf das neue vergrösserte Filesystem ausführen:

# e2fsck -f loop_image_file

5. Filesystem mit folgendem Befehl vergrössern bzw. auf die Grösse anpassen

# resize2fs loop_image_file

6. Virtuellen Server starten.

Jetzt sollte auf dem VServer beim Ausführen von „df“ mehr Platz zur Verfügung stehen.

Das ist eine Übersetzung des Original-Posts "Howto: Resize Xen Loop Disk Image".

Ein Problem entsteht allerdings, wenn man eigene Verzeichnisse für die Sessionfiles definiert. Hier werden die Files dann nicht gelöscht und bleiben bestehen, was das Verzeichnis – je nach Traffic – schnell auf ein paar Tausende Dateien anwachsen lassen kann.

Um die Garbage Collection in PHP zu aktivieren, muss folgender Eintrag in der php.ini (für Apache unter /etc/php5/apache2/php.ini) geändert werden:

VORHER

;session.gc_probability = 0
session.gc_divisor = 100

NACHHER

session.gc_probability = 1
session.gc_divisor = 100

Diese Änderung bewirkt, das bei jedem hundertsten Start einer Session die Sessionfiles gelöscht werden.

Zusätzlich muss dann noch der Cronjob deaktiviert werden. Hierzu einfach /etc/cron.d/php5 mit dem Editor deiner Wahl bearbeiten und die letzte Zeile auskommentieren:

# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm


Was der Grund für diese Deaktivierung bei Ubuntu oder Debian war konnte ich auf die Schnelle nicht herausfinden, werde es aber in einem Update nachliefern.

Wenn in Linux-Distributionen solche Änderungen vorgenommen werden, sollte man aber passende Toolsets liefern, um alle Variationen abzufangen. So ist das nur eine halbe Sache, wenn ich nichts übersehen habe. Der Bug wurde auch schon im Ubuntu-Bugtracker aufgenommen, aber noch keinem zugeordnet.

Weiterführende Links:

• PHP Dokumenation: session.gc-probability
• Bug bei Ubuntu

Crontab

Crontab wird die Tabelle genannt, in der die einzelnen Cronjobs definiert und konfiguriert werden. Die Tabelle enthält pro Zeile den Zeitpunkt und die Befehlsfolge, die ausgeführt werden soll. Der Begriff Crontab setzt sich aus dem griechischen Chronos (Zeit) und lateinischen Tabula (die Tafel, das Brett) zusammen.

Gleichzeitig ist crontab auch das Programm, mit dessen Hilfe man die Crontabs bearbeiten kann. Um die Contab zu bearbeiten, muß folgender Befehl eingegeben werden:

crontab -e

Crontab Syntax

Jeder Cronjob hat folgendes Format:

* * * * * auszuführender Befehl
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └──── Wochentag (0-7, Sonntag ist 0 oder 7)
│ │ │ └────── Monat (1-12)
│ │ └──────── Tag (1-31)
│ └────────── Stunde (0-23)
└──────────── Minute (0-59)


Ein Stern * bedeutet Ausführung wird immer erfolgen, also zu jeder Minute, jeder Stunde, jedem Tag, jedem Monat oder jedem Wochentag. Um die einzelnen Stellen auseinander zu halten, hilft folgendes Diagram:

1 2 3 4 5 Befehl

1 = Minute (0-59)
2 = Stunde (0-23)
3 = Tag (0-31)
4 = Monat (1-12)
5 = Wochentag (0-7, Sonntag ist 0 oder 7)
Befehl = Der auszuführende Befehl.


Für die ersten fünf Stellen, also die Zeiwerte sind folgende Optionen zusätzlich möglich:

* = Ausführung immer (zu jeder…)
*/n = Ausführung aller n
n,x,y = Ausführung um/am n, x und y

Cronjob Beispiele

Um zum Beispiel jede Nacht um 5 Uhr morgens das Backup auszuführen, würde man den Cronjob folgendermaßen anlegen:

0 5 * * * /usr/bin/backup.sh


Einen Sound alle 10 Minuten Abzuspielen könnte wie folgt aussehen:

*/10 * * * * /usr/bin/play_sound.sh


Eine Erinnerungsmail um 8 und um 17 Uhr zu verschicken geht z.B. so:

0 8,17 * * * /usr/bin/send_reminder_mail.sh


An einem bestimmten Tag, beispielsweisse am 31.12. um 23:59 Uhr, eine Mail zu versenden, könnte so aussehen:

59 23 31 12 * (echo "Lass uns die Raketen holen" | mail -s "Gleich knallt es" user@domain.xy)


Ausgabe der Cronjobs

Die Ausgabe der Cronjobs wird standardmässig per Mail an den jeweiligen System-User der den Cronjob eingerichtet hat gesendet. Um dies zu unterdrücken, könnte man die Ausgabe in eine Datei umleiten oder mit Umleitung zu /dev/null komplett verwerfen:

Cronjob-Ausgabe in Logfile umleiten

0 8,17 * * * /usr/bin/script.sh >>/var/log/cron/send_reminder_mail 2>&1


Cronjob-Ausgabe verwerfen

0 8,17 * * * /usr/bin/script.sh >/dev/null 2>&1


2>&1 bedeutet, das sowohl die normale Ausgabe als auch Fehler in die vorher angegebene Datei umgeleitet werden.

Cronjob-Dateien und Verzeichnisse

Zusätzlich zum crontab-Befehl gibt es je nach Distribution Dateien, die systemweite Crontabs beinhalten und nur durch den User root bearbeitet werden können:

/etc/crontab

Die System-Crontab-Datei, in der zusätzlich noch ein System-Benutzer, der den Befehl ausführen soll, mit angegeben werden muß:

1 2 3 4 5 Benutzer Befehl

1 = Minute (0-59)
2 = Stunde (0-23)
3 = Tag (0-31)
4 = Monat (1-12)
5 = Wochentag (0-7, Sonntag ist 0 oder 7)
Benutzer = Benutzername des Benutzers, unter dem der Befehl ausgeführt wird.
Befehl = Der auszuführende Befehl.


Beispiel:
0 8,17 * * * root /usr/bin/script.sh >>/var/log/cron/send_reminder_mail 2>&1
0 3 * * * wwwrun /usr/bin/webjobs_nighly.sh >>/var/log/cron/send_reminder_mail 2>&1


/etc/cron* Verzeichnisse

Eine weitere Möglichkeit Cronjobs anzulegen sind die Verzeichnisse unter /etc/cron*, in denen alle enthaltenen Dateien zum bestimmten Zeitpunkt ausgeführt werden. Die Dateien im Einzelnen

/etc/cron.d/ = Erweiterungen zur /etc/crontab-Datei, gleiche Syntax.
/etc/cron.daily/ = Einmal irgendwann täglich.
/etc/cron.hourly/ = Einmal irgendwann stündlich.
/etc/cron.monthly/ = Einmal irgendwann monatlich.
/etc/cron.weekly/ = Einmal irgendwann wöchentlich.

Die letzten vier werden oft genutzt, wenn ein Job in einem bestimmten Interval erledigt werden muß, der genaue Zeitpunkt hierfür aber unerheblich ist.

Ein Tipp zur Verwendung des Prozentzeichens in Crontabs

Manchmal kommt es vor, dass man – beispielsweisse bei der Verwendung eines Datums – das Prozentzeichen innerhalb eines Crontab-Befehles nutzen möchte:

0 8,17 * * * /usr/bin/script.sh >>/var/log/cron/script_$(date +%Y%m%d).log


Leider wird dies so nicht funktionieren und Crontab verweigert die Ausführung des Cronjobs mit der folgenden oder einer ähnlichen Fehlermeldung:

/bin/sh: -c: line 0: unexpected EOF while looking for matching `)'
/bin/sh: -c: line 1: syntax error: unexpected end of file


Grund hierfür ist, dass Prozentzeichen im 6. Feld einer jeden Crontab-Zeile generell in einen Zeilenumbruch übersetzt werden. Zitat aus der Crontab Manpage:

The sixth field of a line in a crontab file is a string that
is executed by the shell at the specified times. A percent
character in this field (unless escaped by \) is translated
to a NEWLINE character.

Only the first line (up to a `%‘ or end of line) of the com-
mand field is executed by the shell. Other lines are made
available to the command as standard input. Any blank line
or line beginning with a `#‘ is a comment and is ignored.

Die Lösung ist, das Prozenzeichen zu escapen, daher einen Backslash voran zu stellen:

0 8,17 * * * /usr/bin/script.sh >>/var/log/cron/script_$(date +\%Y\%m\%d).log


So steht dann auch der Nutzung des Datums mit Prozentzeichen nichts mehr im Wege.

Crontab und gut?

Ich hoffe, ich konnte einen kleinen Einblick in die Cronjobs unter Linux geben und dem ein oder anderen bei der Syntax behilflich sein. Dieser Artikel entsteht auch mit etwas Eigennutz, da ich auch oft überlegen muß, wie die genaue Reihenfolge in der Crontab nun ist. Es gibt natürlich noch eine Menge anderer Tools wie at, anacron, fcron und so weiter. Cronjob hat für mich jedoch sehr zuverlässig gearbeitet, weshalb ich andere Tools noch nicht in Betracht gezogen habe.

Let the crons work!

Wer auf die Twitter-API zugreift kennt das Problem des ständigen Polling der API, d.h. man muß in der Software mit Hilfe von Cronjobs oder ähnlichem aller paar Sekunden nach neuen Tweets schauen.

Das hat sich letztes Jahr zum Glück mit der Twitter Streaming API geändert. Nun kann man per Stream auf die Tweets zugreifen, eine tolle Sache!

Um den Stream mit Ruby zu nutzen gibt es ein Gem von Intridea genannt TweetStream. Mit diesem Gem ist es sehr einfach möglich Tweets zu lesen, sogar ein Daemon ist enthalten.

require 'rubygems'
require 'tweetstream'

# The third argument is an optional process name.
TweetStream::Daemon.new('user','pass','tracker').track('keyword1','keyword2') do |status|
  # Do something like dump the status to ActiveRecord
  # or anything else you want.
end

Wo man es herbekommt, wie man es installiert und nutzt erklären Sie in Ihrem Blog:

TweetStream: Ruby Access to the Twitter Streaming API

Happy Streaming!

Für Webentwickler ist es immer wichtig zu wissen, welche Browser am meisten genutzt werden. Bisher war dies immer der Internet Explorer in der Version 6 oder 7. Doch seit einigen Wochen oder sogar Monaten hat sich der Firefox in der Version 3.5 den ersten Platz erkämpft. Mit dem heutigen Datum sieht die Top 5 der meist genutzen Browser laut der 4stats Browser Statistik mit Version so aus:

1. 26.20% Firefox 3.5
2. 17.42% Internet Explorer 8.0
3. 16.96% Internet Explorer 7.0
4. 13.23% Internet Explorer 6.0
5. 11.56% Firefox 3.0

Safari liegt mit 3.44% auf Platz 7, gefolgt von Opera (1.9%) und Google Chrome (1.7%).

Der Wechsel an die Spitze ist sicher auf die Schnelligkeit des Firefox und den wachsenden Bekanntheitsgrad zurückzuführen. Wir dürfen gespannt sein, ob es bei einem erneuten Versions-Update des Firefox so bleibt und ob der Internet Explorer dank Windows 7 vielleicht doch Platz 1 wieder in Beschlag nimmt. In der Browser Statistik der Marktanteile ohne Versionsnummer ist der Internet Explorer mit fast 48% immer noch auf Platz 1. Aber auch hier ist der Firefox mit ca. 40% dicht dran. Das Rennen der Browser geht weiter!

if ($host != 'deine_domain.com' ) {
rewrite ^/(.*)$ http://deine_domain.com/$1 permanent;
}

Das ganze packt man in die Konfiguration eines Server bzw. VirtualHosts und schon ist die Domain nur noch ohne www. und unter einer Adresse – hier deine_domain.com – erreichbar. Alles andere wird auf diese Domain weitergeleitet.

Anhand dieser Zeilen könnt Ihr die Weiterleitung ganz einfach auf Eure Bedürfnisse anpassen. Viel Spaß!

Danke an Steven Bristol.

bash: line 1: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: remote command not found (code 127) at io.c(453) [receiver=x.x.x]


Hat man keinen Root-Zugriff auf dem Remote Server, so stellt dies kein Problem dar. Rsync kann auch ganz leicht im eigenen Home-Verzeichnis installiert werden. Hierfür geht man einfach auf die rsync-Webseite unter http://samba.anu.edu.au/rsync/ und lädt sich die aktuelle rsync-Version (in diesem Beispiel 3.0.6) herunter, entpackt und kompiliert diese:

wget http://samba.anu.edu.au/ftp/rsync/src/rsync-3.0.6.tar.gz
tar -xvzf rsync-3.0.6.tar.gz
cd rsync-3.0.6
./configure --prefix=/pfad/zu/deinem/homedir
make


Und schon hat man eine lauffähige rsync-Version installiert und muß nun noch in der .bashrc oder .cshrc den entsprechenden Pfad hinzufügen:

vi ~/.bashrc


Folgende Zeile einfügen:

export PATH=$PATH:/pfad/zu/deinem/homedir/rsync-3.0.6

Anstatt /pfad/zu/deinem/homedir natürlich den Pfad zu deinem Homeverzeichnis.

Jetzt kann man ganz normal vom entfernten Rechenr den rsync starten

rsync -e ssh -avzr remoteserver:~/wasauchimmer/ /lokaler/pfad/wasauchimmer/

Das funktioniert natürlich nicht nur mit rsync, sondern auch mit anderen Tools, die ansich kein Root-Recht zum installieren benötigen.

Seiten-Template mit PHP-Code im Theme Ordner von WordPress anlegen

Lege eine neue Datei im Theme-Ordner unter wp-content/theme//deintemplate.php mit folgendem Inhalt an:

<?php
/*
Template Name: DeinTemplate-Name
*/
?>
<?php get_header(); ?>


<?php if (have_posts()) : ?>
<?php while (have_posts()) : the_post(); ?>


<div class="post page">
  <h2><?php the_title(); ?></h2>
  <?php the_content(); ?>
</div>


<?php endwhile; ?>
<?php endif; ?>


<?php echo "Hier kommt mein tolles PHP-Script bzw. der PHP-Code rein!"; ?>


<?php get_footer(); ?>

Wichtig hierbei ist der Kommentar, der unbedingt enhalten sein muss. WordPress erkennt anhand des Strings "Template Name", das es sich um ein Template handelt. Die Funktion get_header bindet das Header Template ein (wie gewohnt) und die Funktion get_footer das Footer-Template. Nach dem Header wird mit den Post-Funktionen der Inhalt der Seite, also die Headline und der Text, ausgelesen.
Anstelle des echo-Befehles (Hier kommt mein…) kann jetzt gewünschter PHP-Code eingefügt werden.

Seiten-Template auswählen und Seite mit PHP-Code anlegen

Jetzt kannst du im WordPress-Admin in der Seiten-Verwaltung unter "Seiten" ganz normal eine Seite anlegen und auf der rechten Seite neben dem Formular das erstellte Seiten-Template mit dem Namen aus dem Kommentar auswählen. Seite veröffentlichen und schon wird der Code (der hoffentlich fehlerfrei ist) auf der erstellten Seite ausgeführt.

Das Verfahren kann man natürlich beliebig weiterführen und komplexere Anwendungen in das Template einbinden. Das kurze Tutorial hier soll lediglich als Einstieg in dieses Thema dienen.

Mehr Info bei WordPress: Theme-Page-Templates

Webseite: What Browser?

Via Googlewatchblog. Offizieller Blogpost bei Google.

Hast du auch lustige Befehle?
Bitte schicke Sie mir oder schreib Sie in die Kommentare, ich werde Sie dann der Liste hinzufügen. Vielen Dank!

Liste lustiger Linux/Unix-Kommandos

Durch die Blume:

bash:~# netstat -tulpen

Wenn man hungrig ist:

bash:~# ps haxen

Linux will keine Liebe machen:

bash:~# make love
make: *** No rule to make target `love'. Stop.

Krieg zum Glück auch nicht:

bash:~# make war
make: *** No rule to make target `war'. Stop.

Ohne Widerrede dagegen wird folgendes ausgeführt:

bash:~# touch me

Versaut geht es gar nicht:

bash:~# %blow
-bash: fg: %blow: no such job

Keine Anleitung für Frauen.

bash:~# nice man woman
No manual entry for woman

Funny

bash:~# \(-
-bash: (-: command not found

Ne Runde schlafen:

bash:~# while true; do sleep 1; done

Und weg:

bash:~# ex - und hopp
2 Dateien zur Bearbeitung

Einfach mal Klamotten zählen:

bash:~# socklist

Linux ist auch kein Geldesel:

bash:~# find money
find: money: No such file or directory

Wichtige Befehlsfolge:

unzip; strip; touch; finger; grep; mount; fsck; more; yes; fsck; fsck; fsck; umount; sleep

Quellen:
http://www.linuxfocus.org/Deutsch/July1999/article104.html
http://www.tbi.univie.ac.at/~ronke/FUN/unix.html

Oft ist es notwendig aus einem System-Logfile, Daten wie Befehle, Dateinamen, User-Agents, Zeiten oder was auch immer zu zählen, zu summieren und zu sortieren. Möchte man zum Beispiel wissen, welcher Befehl auf einem Webserver am meissten aufgerufen wurde, reicht ein Einzeiler:

cat access_log | awk '{print $6}' | sort | uniq -c | sort -nr | less


Was hier passiert, möchte ich kurz erklären:

cat access_log
Hier öffnen wir die Datei access_log und leiten den Inhalt an den Standard-Output – hier unsere Konsole – zur Ausgabe weiter.

awk '{print $6}'
Mit Awk können wir uns einfach Teile einer Ausgabe aus einem Text herausfiltern. Hier die 6. Stelle – der Befehl. Das Standard-Trennzeichen von awk ist das Leerzeichen, was aus diesem Grund nicht mit angegeben werden muss.

sort
Diese Befehl sortiert die aktuelle Ausgabe.

uniq -c
Hier werden gleich zwei Sachen erledigt. Es werden doppelte Einträge entfernt und gleichzeitig die Anzahl der Vorkommnisse als Prefix vor jede Zeile gesetzt.

sort -nr
Sortiert diese Ausgabe nochmals, jetzt jedoch nach Nummern und rekursiv, so dass der Eintrag mit dem meißten Ergebnissen oben steht.

less
Hier kann wahlweisse auch tail verwendet werden. Sollte klar sein. Less lässt uns die ersten Zeilen in normaler Geschwindigkeit lesen, in dem es die Ausgabe nach vollem Bildschirm anhält.

Die Ausgabe des ganzen Befehles sollte nun ungefähr so aussehen:

528162 "GET
8583 "POST
242 "HEAD
15 "OPTIONS
2 "PUT


Wir können hiermit nun beliebig benötigte Daten zählen und uns schnell einen Überblick über die Anzahl der jeweiligen Vorkommnisse anzeigen lassen. Eine kleine Linux-Live-Statistik sozusagen.

  def distance_of_time_in_words(from_time, to_time = 0, include_seconds = false)

    from_time = from_time.to_time if from_time.respond_to?(:to_time)
    to_time = to_time.to_time if to_time.respond_to?(:to_time)
    distance_in_minutes = (((to_time - from_time).abs)/60).round
    distance_in_seconds = ((to_time - from_time).abs).round

    case distance_in_minutes
      when 0..1
        return (distance_in_minutes == 0) ? 'weniger als einer Minute' : 'einer Minute' unless include_seconds
        case distance_in_seconds
          when 0..4   then 'weniger als 5 Sekunden'
          when 5..9   then 'weniger als 10 Sekunden'
          when 10..19 then 'weniger als 20 Sekunden'
          when 20..39 then 'einer halben Minute'
          when 40..59 then 'weniger als einer Minute'
          else             '1 Minute'
        end

      when 2..44           then "#{distance_in_minutes} Minuten"
      when 45..89          then 'ca. 1 Stunde'
      when 90..1439        then "ca. #{(distance_in_minutes.to_f / 60.0).round} Stunden"
      when 1440..2879      then '1 Tag'
      when 2880..43199     then "#{(distance_in_minutes / 1440).round} Tagen"
      when 43200..86399    then 'ca. 1 Monat'
      when 86400..525599   then "#{(distance_in_minutes / 43200).round} Monaten"
      when 525600..1051199 then 'ca. 1 Jahr'
      else                      "#{(distance_in_minutes / 525600).round} Jahren"
    end
  end

Nicht über den Funktions-Namen wundern, time_ago_in_words ist ein Alias für distance_of_time_in_words.

Update:

Viel einfacher wäre es natürlich, die I18n-Funktionen, die ab der Rails-Version 2.2 oder besser 2.3 enthalten sind zu nutzen. Hierfür muß man einfach in der Datei config/environment.rb den String

config.i18n.default_locale = :de

(nach Rails::Initializer.run do |config| und vor end) einfügen und eine Datei unter config/locales/de.yml mit folgendem Inhalt anlegen:

# German translations for Ruby on Rails 
# by Clemens Kofler (clemens@railway.at)
de:
  datetime:
    distance_in_words:
      half_a_minute: 'eine halbe Minute'
      less_than_x_seconds:
        zero: 'weniger als 1 Sekunde'
        one: 'weniger als 1 Sekunde'
        other: 'weniger als {{count}} Sekunden'
      x_seconds:
        one: '1 Sekunde'
        other: '{{count}} Sekunden'
      less_than_x_minutes:
        zero: 'weniger als 1 Minute'
        one: 'weniger als eine Minute'
        other: 'weniger als {{count}} Minuten'
      x_minutes:
        one: '1 Minute'
        other: '{{count}} Minuten'
      about_x_hours:
        one: 'etwa 1 Stunde'
        other: 'etwa {{count}} Stunden'
      x_days:
        one: '1 Tag'
        other: '{{count}} Tage'
      about_x_months:
        one: 'etwa 1 Monat'
        other: 'etwa {{count}} Monate'
      x_months:
        one: '1 Monat'
        other: '{{count}} Monate'
      about_x_years:
        one: 'etwa 1 Jahr'
        other: 'etwa {{count}} Jahre'
      over_x_years:
        one: 'mehr als 1 Jahr'
        other: 'mehr als {{count}} Jahre'
    prompts:
      second: "Sekunden"
      minute: "Minuten"
      hour: "Stunden"
      day: "Tag"
      month: "Monat"
      year: "Jahr"

Quelle: Original-Datei mit noch mehr Übersetzungen (auch für Active-Record-Messages und in anderen Sprachen) gibt es hier.

Bild von Darren Hester auf flickr.

Hersteller Audi Opel Mercedes Volkswagen


Den Wert der aktuell gewählten Option erhalten wir mit:

$('#hersteller').val();


Möchten wir den Text, also Inhalt der aktuell gewählten Option erhalten, geht dies über den zusätzlichen Selektor „:selected“ und die Funktion „text“:

$('#hersteller :selected').text();


Auch das Auslesen von mehreren gewählten Select-Optionen/Werten ist mit dem Selektor „:selected“ und einer each-Schleife möglich:

$('#hersteller :selected').each(function(i, option){
// hier können wir den Inhalt von "option" verwerten
});


Oder das Setzen einer Select-Option:

$('#hersteller').val("1");


Eigentlich alles ganz easy oder? jQuery macht Spass!

RewriteEngine on
RewriteCond %{HTTPS} on
RewriteRule ^robots\.txt$ robots_https.txt


Die Datei robots_https.txt sollte so aussehen, um alle Suchmaschinen-Bots (Googlebot etc.) und Seiten zu verbieten:

User-agent: *
Disallow: /


United-Domains verschenkt an alle Blogger Ihre Domain-Weltkarte im laminierten Großformat 120 cm x 60 cm. Die Karte zeigt alle Länder-Domains (ccTLD’s) auf einer Weltkarte und bietet ebenso eine Übersicht über alle Länder-Codes mit Längen- und Breitengraden. Alles was ein Blogger dafür tun muss, ist einen kurzen Artikel zu schreiben, auf United-Domains oder die Domain-Weltkarte zu verlinken und schon kann man sein Büro mit dieser Karte verschönern. Mehr Infos zur Aktion gibt es hier bei United-Domains. i.ch ma.ch m.it – dank.es. Wirklich eine klasse Idee – auch marketingtechnisch – und ein schöner Blickfang für das Büro.

Via Caschy.