Wer früher einen beschränkten SSH-Zugriff auf einem Server realisieren wollte, musste früher auf rssh und eine chroot-Umgebung zurückgreifen. Die Einrichtung war entsprechend aufwändig. Mit einer aktuellen Version von SSH kann man sich diese Arbeit sparen.

Vier Schritte sind notwendig, um einen Zugriff herzustellen:

1. Gruppen anlegen und User hinzufügen

   In diesem Beispiel werden die beiden Gruppen groupA und groupB verwendet.

2. Verzeichnisse mit passenden Rechten einrichten

    Verzeichnis          Rechte

srv
├── groupA               root:root
│   └── files            groupA:groupA
│       ├── test1.txt
│       └── test2.txt
├── groupB               root:root
│   └── files            groupA:groupA
│       ├── test1.txt
│       └── ...
└── ...

3. Konfiguration des SSH-Serves anpassen

   Für jede Gruppe muss ein eigener sog. Match-Block angelegt werden:

Match Group groupA
  ChrootDirectory /srv/groupA
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp
Match Group groupB
  ChrootDirectory /srv/groupB
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Nach einem Neustart des SSH-Dämons gelangt man mittels sftp in die jeweiligen Verzeichnisse, muss aber, bevor Dateien abgelegt werden können, in das Unterverzeichnis files wechseln, weil nur dort die entsprechenden Schreibrechte bestehen.

cookiecutter ("Ausstechförmchen") erzeugt aus Vorlagen beliebige Projektgrundstrukturen und kann dabei vordefinierte Werte einsetzen sowie fehlende erfragen.

Ziel von cookiecutter und anderen sogl. Scaffolding-Werkzeugen ist, beim Erstellen neuer Projekte nur noch die nötigsten Schritte per Hand durchführen zu müssen.

Existiert eine passende Vorlage, kann mit

# cookiecutter <Name der Vorlage>

im aktuellen Verzeichnis ein Projekt angelegt werden. Die benötigten Vorlagen können dabei lokal und auch auf GitHub liegen. Ein Beispiel aus der Projektdokumentation:

# cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git

Die von GitHub bezogene Vorlage wird zusätzlich im Verzeichnis ~/.cookiecutters/ abgelegt und kann dann später wie eine lokale Vorlage direkt verwendet werden:

# cookiecutter ~/.cookiecutter/cookiecutter-pypackage

Angaben, die unabhängig von den Vorlagen immer gleich bleiben, wie bspw. der Name des Entwicklers oder die E-Mail-Adresse, lassen sich in der Datei ~/.cookiecutterrc speichern:

default_context:
  full_name: "fuller"
  email: "fuller@daemogorgon.net"
  github_username: "fuller"
cookiecutters_dir: "/home/.../my-custom-cookiecutters-dir/"

Im Abschnitt default_context können beliebige Schlüssel-Wert-Paare stehen. Sollen die Vorlagen woanders als im Standardverzeichnis liegen, definiert man dies mit cookiecutters_dir.

meine-vorlage/
├── {{ cookiecutter.repo_name }}/
│   └── ...
└── cookiecutter.json

{
  "full_name": "John Doe",
  "email": "jdoe@mail.com",
  "github_username": "johnd",
  "project_name": "My New Project",
  "repo_name": "my_project",
  "project_short_description": "My project ...",
  "release_date": "2013-12-11",
  "year": "2013",
  "version": "0.1"
}

{% for item in list %}
  ...
{% endfor %}

{{ item.href }}

{% set navigation = [('index.html', 'Index'), ('about.html', 'About')] %}
{% set key, value = call_something() %}

{% for item in seq -%}
  {{ item }}
{%- endfor %}

{{ name|striptags|title }}}

{# ...
  ...
#}

{{ '{{' }}

...
{% block head %}
...
{% endblock %}

{% extends "base.html" %}
...
{% block head %}
  {{ super() }}
  ...
{% endblock %}
...

<title>{%  block title %}{% endblock %}</title>
<h1>{{  self.title() }}</h1>
{%  block body %}{% endblock %}

{% for item in seq %}
  <li>{% block loop_item %}{{ item }}{% endblock %}</li>
{% endfor %}

{% for item in seq %}
  <li>{% block loop_item scoped %}{{ item }}{% endblock %}</li>
{% endfor %}

{{ user.username|e }}

{% macro input(name, value='', type='text', size=20) -%}
  <input type="{{ type }}" name="{{ name }}" value="{{
      value|e }}" size="{{ size }}">
{%- endmacro %}

<p>{{ input('username') }}</p>
<p>{{ input('password', type='password') }}</p>

# generate.py

from ast import literal_eval
import sys
from jinja2 import Environment, FileSystemLoader

template_dir = "templates"
jinja = Environment(loader=FileSystemLoader(template_dir))


def render(template_filename, args):
  tpl = jinja.get_template(template_filename)
  content = tpl.render(args)

  return content


def help():
    print("Usage: {0} <template filename> <output|-> <dict>".format(sys.argv[0]), file=sys.stderr)
    print("e.g. /usr/bin/python3 generate.py tmp.tmp - '{\"a\":1, \"bla\": \"blub\"}'", file=sys.stderr)
    print("You *must* use the single quotes, otherwise your shell will try to interpret some characters!", file=sys.stderr)

if __name__ == "__main__":
    if len(sys.argv) != 4:
        help()
        sys.exit(1)

    template_filename = sys.argv[1]
    output = sys.argv[2]

    args = sys.argv[3]
    kwargs = literal_eval(args)

    if template_filename == "":
        print("You must give a template filename as first argument", file=sys.stderr)
        sys.exit(1)

    rendered_content = render(template_filename, args)

    if output == "-":
        output_handle = sys.stdout
        output_handle.write(content)
    else:
        with open(output, 'w') as output_handle:
            output_handle.write(content)

Nikola ist ein Werkzeug zur Erzeugung statischer Webseiten.

Warum statisch und nicht dynamisch wie WordPress, Joomla etc.? Es gibt einige Gründe, die für statische Seiten sprechen:

Sicherheit:

Bis auf den Webserver ist auf Serverseite (neben dem Betriebssystem natürlich) keine weitere Software involviert, wenn statische Inhalte ausgeliefert werden. Bei klassischen LAMP-Stacks wie MediaWiki, WordPress, Joomla und Drupal läuft neben einer Datenbank (oft MySQL oder jetzt auch MariaDB) immer eine Skriptsprache. Gerade PHP befindet sich oft im Fokus von Angreifern (s. bspw. die PHP-Themenseite auf Heise).

Performanz und Ressourcen:

Selbst kleine und einfache Webserver wie thttpd (bzw. der Fork sthttpd) können statische Seiten sehr schnell ausliefern, wie ein (etwas älterer) Benchmark des thttpd-Entwicklers zeigt. Der Ressourcenverbrauch hält sich dabei in Grenzen und das Einrichten des Webservers reduziert sich im Wesentlichen auf die Angabe des Verzeichnisses, in dem sich die HTML-Dateien befinden.

Vendor Lock-In:

Die Verwendung von Datenbanken, die Abhängigkeit von speziellen Eingabeformaten und die enge Anbindung an eine bestimmte Webserver-Software erschweren einen Wechsel des Systems, wenn einer der Bausteine nicht mehr gepflegt wird oder massive Sicherheitsprobleme aufweist. Bei statischen Seiten besteht dieses Problem nicht, denn jeder Webserver kann statische Seiten ausliefern.

Verwaltung und Backup:

Die Quelldateien für einen Generator wie Nikola bzw. die fertigen HTML-Dateien lassen sich einfach wegsichern, entweder direkt mit einer Backup-Software oder besser mit Hilfe einer Versionsverwaltung wie Mercurial oder Subversion. Zwar lassen sich auch Datenbanken recht einfach dumpen, aber für eine vollständige Sicherung muss zusätzlich die Anbindung der Datenbank und die Integration der Skriptsprache bzw. die zugehörige Konfiguration des Webservers gesichert werden.

Es gibt auch Gründe, die gegen statische Seiten sprechen:

Installation zusätzlicher Software:

CMS-Systeme benötigen für die Verwaltung nur den Webbrowser. Um statische Seiten zu erstellen, muss mindestens ein Editor installiert sein. Meist wird ein spezieller Editor wie bspw. Bluefish verwendet. Bluefish ist ein HTML-Editor mit Syntax Highlighting, integrierter Projektverwaltung und Deploymentfunktionalität.

Design der Website:

CMS-Systeme garantieren ein einheitliches Aussehen der Website über einen Template-Mechanismus. Die meisten HTML-Editoren bieten einen solchen Mechanismus auch an, ggf. muss aber für die Erstellung der Templates eine weitere Auszeichnungssprache beherrscht werden.

Erstellen/Bearbeiten von Seiten:

CMS-Systeme bieten in der Regel eine WYSISYG-Bearbeitung der Inhalte an, wie man sie von Office-Produkte wie LibreOffice kennt. Die meisten HTML-Editoren und Generatoren hingegen erfordern Kenntnisse von Auszeichnungssprachen wie HTML, CSS, Markdown, reST, Jinja, HTML, CSS usw.

Aufwand:

Der Aufwand bei der Erstellung/Änderung einer Seite ist höher als bei klassischen CMS-Lösungen: Quelldatei erstellen/bearbieten, kompilieren, auf den Webserver laden.

Für Entwickler, die den Umgang mit Auszeichnungssprachen, Compilern und Versionsverwaltungen gewohnt sind, ist das alles kein Hindernis. Allerdings ist HTML als Auszeichnungssprache doch recht wortreich und die Umsetzung eines konsistenten Layouts ist ohne Unterstützung durch Werkzeuge nur bedingt umzusetzen.

Hier kommen die Generatoren ins Spiel. Sie bieten alternativ zu HTML Support für vereinfachte Auszeichnungssprachen wie Markdown und reST und nutzen Templates, um für ein einheitliches Look-and-Feel zu sorgen.

Es gibt viele statische Blog-/Website-Generatoren (jekyll, hyde, pelican, blacksmith, acrylamid u.v.m.), warum gerade Nikola?

• wird aktiv entwickelt
• Übersetzungen in mehr als 10 Sprachen
• Syntax-Highlighting von Quellcode
• flexible Eingabe: reST, Markdown, bbcode, Wiki, HTML, txt2tags, textile
• umfangreich dokumentiert

configure --prefix=$HOME/opt/python
make
make install

PATH=$HOME/opt/python/bin:$PATH
LD_LIBARY_PATH=$HOME/opt/python/lib;$LD_LIBARY_PATH

cd $HOME/opt
python3.3 -m venv nikola
cd nikola
source bin/activate

wget http://python-distribute.org/distribute_setup.py
bin/python distribute_setup.py install
bin/easy_install pip

bin/pip install -U nikola

pip install requests

pip install http://github.com/lepture/python-livereload/zipball/master

nikola init daemogorgon.net
cd daemogorgon.net

##        % if not post.meta('nocomments'):
##            ${comments.comment_link(post.permalink(), post.base_path)}
##        % endif

.. title: [gerade eingegeben]
.. slug: [entspricht dem Seitennamen; "bereinigte" Version des Titels, also
     entfernte Leerzeichen etc.]
.. date: [aktuelles Datum]
.. tags:
.. link: [Hinweis auf Originalquelle?]
.. description: [hilfreich für Suchmaschinenoptimierung]

.. TEASER_END

REDIRECTIONS = [ ("von", "nach") ]

REDIRECTIONS = [
  ("wp-content/uploads/wmanager_021.tgz", "files/wmanager_021.tgz")
  ]

Verweis auf die Seite: :doc:`nikola-static-site-and-blog-generator`

rsync -av --delete  output/*  user@host.net:/path/to/dir

COMMENT_SYSTEM = ""
COMMENT_SYSTEM_ID = ""