Komischerweise gibt es kein automatisch erstelltes Start/Stop-Skript für Subversion unter Ubuntu-Server.
Hierzu habe ich das unten aufgelistete Skript geschrieben.
Dieses muss anschließend noch per Symlink mit den entsprechenden Runlevels verknüpft werden.
Nach langem Probieren und suchen in den Weiten des Internet habe ich eine Lösung gefunden.
Simpel (wer hätte das gedacht) – aber wie soll man da denn so draufkommen?
Die Lösung ist, dass man im Setup der Anmeldeseite folgenden Wert einfügt bzw. an entsprechender Stelle einfügt:
Anfangs scheint es schwieriger zu sein, den Newsletter für den Empfänger zu personalisieren als es scheint.
Im Nachhinein ist es garnicht so schwer.
Um einen personalisierten Newsletter zu verschicken benötigt die Typo3-Installation (T3) die Extension df_direct_mail_subscription.
Diese sorgt dafür, dass der Interessent bereits bei der Anmeldung die Anrede auswählen kann (männlich/weiblich).
Um dies auch beim Versandt des Newsletters zu erreichen sind folgende Schritte nötig:
Wie oft sucht man eine Seite auf der man mögliche Marker für einen Newsletter findet?
Ich habe nach längerer Suche etwas in einem Typo3 Forum gefunden:
Diese Marker beziehen ihre Werte aus der Datenbank. Dabei wird auf die Tabelle “tt_address” zugegriffen.
###USER_title###
###USER_name### (full name)
###USER_email###
Optional (falls diese in der Tabelle tt_adress existieren)
###USER_firstname### (first name calculated)
###USER_uid### (the unique id of the recipient)
###USER_phone###
###USER_www###
###USER_address###
###USER_company###
###USER_city###
###USER_zip###
###USER_country###
###USER_fax###
###SYS_TABLE_NAME###
###SYS_MAIL_ID###
###SYS_AUTHCODE###
(###USER_NAME### und ###USER_FIRSTNAME### fügen die Namen in großen Buchstaben ein!)
Wenn alle nötigen Einstellungen für Direct_Mail (DM) getätigt wurden, so muss als Sahnehäubchen der Crontab für den automatischen Versand eingerichtet werden.
Da auf meinem Web-Server Plesk zur Verwaltung eingerichtet ist, kann der Crontab bequem mit Plesk eingerichtet werden.
Was man dabei beachten muss, sind die Rechte und Owner der einzelnen Skripte.
Um das Ausprobieren verschiedener Ansätze zu vermeiden, habe ich mein TYPO3 Verzeichnis (www.domain.com/cms) kurzerhand dem Apache als Owner gegeben und zusätzlich den Apache als Owner für das TYPO3-Source Verzeichnis bestimmt.
Ergebnis: Im Backend wird mir angezeigt, dass der Crontjob läuft und eingerichtet ist.
Wer einen eigenen RSS-Feed betreibt und nicht auf die angenehmen Module vieler Systeme zurückgreifen kann, der wird sicherlich das Problem kennen, dass der Feed in manchen Readern nicht angezeigt wird. Gar schlimmer, wenn eine Fehlermeldung erscheint.
Hierfür gibt es einen guten Helfer: Einen Feed Validator.
Wer einen Router hat, der eine automatische Aktualisierung der IP bei Dyndns.org kann, wird vielleicht feststellen, dass es ab und an nicht funktioniert.
Wenn auf einen Linux-Rechner zurückgegriffen werden kann, so kann man sich bei Dyndns ein Tool runterladen, welches man als Daemon einrichten kann.
Dabei muss darauf geachtet werden, dass man den Daemon nicht als ‘root’ startet. Es ist zu empfehlen einen separaten Benutzer anzulegen (z.B. ‘dyndns’). Dieser hat dann nur Zugriff auf sein Home-Verzeichnis. Dort sollte die inadyn-Datei hinterlegt werden und mit ‘chmod 700′ entsprechend bearbeitet werden.
Nun noch eine config-Datei in ‘/etc ‘ als ‘root’ erstellen. Dort die entsprechenden Parameter eintragen.
Wenn der Benutzer ‘dyndns’ die Datei ‘inadyn’ aufruft, wird automatisch auf die config zurückgegriffen.
Es muss dabei darauf geachtet werden, dass man ‘inadyn’ nicht als Prozess via Crontab startet, da multiple Instanzen zu einer Sperrung des Dyndns-Accounts führen.
Das Beste ist, wenn man inadyn als Daemon einrichtet.
Ich habe mich schon des öfteren gefragt, welche Bedeutung die verschiedenen Runlevel unter Linux (meist im Verzeichnis /etc/) zu bedeuten haben.
Dass der Eine oder Andere für das Starten oder Beenden steht ist klar.
Da ich aber einfacher hier in meinem Blog suchen möchte, habe ich hier eine Tabelle eingefügt mit den verschiedenen Runlevel:
| Runlevel | Beschreibung |
|---|---|
| 0 | Shutdown. Alle Netzverbindungen werden geschlossen, Dateipuffer werden geschrieben, Mounts auf Partitionen werden entfernt (d. h. die im Verzeichnisbaum eingebundenen Datenträger werden ausgehangen). |
| S | Single-User-Runlevel; niedrigster Systemzustand für Wartungsarbeiten, in dem ausschließlich Systemressourcen wie Festplatten oder Dateisysteme aktiv sind. |
| 1 | Einzelnutzerbetrieb ohne Netzwerk mit ausschließlich lokalen Ressourcen. In vielen Implementationen identisch mit ‘S’. |
| 2 | Lokaler Mehrnutzerbetrieb ohne Netzwerk mit ausschließlich lokalen Ressourcen. Unter einigen Linuxdistributionen (z. B. Debian) wird in Runlevel 2 auch das Netzwerk konfiguriert. |
| 3 | Netzwerkbetrieb, über das Netzwerk erreichbare Ressourcen sind nutzbar, eine grafische Oberfläche steht nicht zur Verfügung. Firewalls sollten aktiviert werden. |
| 4 | Ist normalerweise nicht definiert. Kann aber für diverse Dienste genutzt werden. |
| 5 | wie 3, zusätzlich wird die grafische Oberfläche bereitgestellt. |
| 6 | Reboot. Alle Netzverbindungen werden geschlossen, Dateipuffer werden geschrieben, Mounts auf die Partitionen werden entfernt. |
Java
for(<typ> <name>: <source>) {…}
<typ>: Ist der einzelne Wert von <source>
<name>: Ist der temporäre Name für ein Einzelnes Element aus <source>
<source>: Ist wie besagt, die Variable von der die Elemente stammen.