Archiv ‘Linux’

Sonntag, 26. Januar 2014

Shell-Script-Befehl auf STDOUT ausgeben und danach ausführen

Viele meiner Scripts sind mit hoher Verbosität programmiert, damit ich während der Entwicklung weiss, wo allfällig die Ausführung abbricht. Hierzu gehört auch, dass ich komplexe Befehle vor der Ausführung ausgebe. Damit kann ich den Befehl kopieren und beim Debugging manuell auf der Kommandozeile ausführen, um vielleicht weitere Hinweise auf das Problem zu erhalten.

Doch wie macht man das, wenn man bspw. bei rsync Pfadangaben mit Leerschlägen drin hat, die vom Tool dann auch effektiv erkannt und verarbeitet werden sollen? Hier die Lösung:

...
$SOURCE="/Users/mario/Pictures/iPhoto Library/"
$DEST="/Volume/Sicherungs Ordner mit vielen Leerzeichen/"
...
COMMAND="rsync $OPTS \"$SOURCE\" \"$DEST\""
...
echo "Executing '$COMMAND' ..."
...
eval $COMMAND
...

Die ganze Chose steht und fällt mit eval. Wird nur $COMMAND ausgeführt, stolpert rsync über die ordentlich mit Anführungszeichen versehenen Pfade mit Leerzeichen.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Shell-Scripte mit vielen Optionen

Komplexe Shell-Scripte, welche ein Unix-Tool mit unzähligen Optionen aufrufen, muss man ab und zu debuggen. Damit dies möglichst einfach funktioniert, habe ich mir angewöhnt, die Optionen so zu notieren, damit ich jede einzelne Option mit einem Tastendruck auskommentieren kann:

...
OPTS=""
OPTS="$OPTS --verbose"
OPTS="$OPTS --archive"
OPTS="$OPTS --no-owner"
OPTS="$OPTS --no-group"
#OPTS="$OPTS --delete" # WILL DESTROY EVERYTHING! DO NOT UNCOMMENT
OPTS="$OPTS --progress"
...
rsync $OPTS "$SOURCE" "$DESTINATION"
...

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Das Mac OS X Home-Verzeichnis mit rsync über SSH auf eine Synology Diskstation sichern

Nachdem ich den schlüsselbasierten Login hingekriegt hatte, stand ich bereits wieder vor dem nächsten Problem: Mein rsync-Script zur Sicherung meines Mac OS X Home-Verzeichnis in einen Unterordner auf meinem Home-Verzeichnis auf dem Synology NAS brach mit folgender Fehlermeldung ab:

...
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only
...

Wieso denn das? Mit dem Synology-Konto meines Raspberry Pi klappt die ganze Chose problemlos!

Mit den Hinweisen unter Rsync over ssh: “ERROR: module is read only” suddenly appeared wurde ich auf den richtigen Pfad gelenkt: Ich musste meinem Benutzer mittels des Synology Web-GUIs Schreibrechte auf den Homes-Ordner geben:

  1. Control Panel
  2. Users
  3. %BENUTZER% auswählen
  4. Edit
  5. Privileges Setup
  6. homes
  7. [x] Read/Write
  8. OK

Seither klappt die rsync-Synchronisierung. Ob ich aber damit eine Sicherheitslücke geöffnet habe?

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Sich schlüsselbasiert per SSH auf einer Synology Diskstation einloggen

Im Grunde ein einfaches Unterfangen, welches im Internet auf unzähligen Seiten dokumentiert ist. Kurzfassung: Auf dem eigenen Arbeitsrechner einen privaten und öffentlichen Schlüssel erstellen, auf der Synology Diskstation den SSH-Zugang aktivieren, eine Login-Shell einrichten und dort dann unter ~/.ssh/authorized_key den öffentlichen Schlüssel ablegen.

Was ich vor einigen Monaten mit meinem Raspberry Pi erfolgreich und innert kurzer Zeit hingebracht habe, wollte mich gestern während eineinhalb Stunden auf Trab halten. Neu wollte ich auch meinen persönlichen Account mit einem schlüsselbasierten SSH-Zugang ausstatten. Doch während der schlüsselbasierte Login mit dem Raspberry Pi-Konto problemlos funktionierte, wollte es mit dem privaten Konto einfach nicht klappen, obwohl die Konfiguration identisch war.

Lösung

Die nach unzähligen Pröbelversuchen eruierte Ursache: Das Home-Directory meines Benutzers war nicht mit den korrekten Berechtigungen versehen:

VAULT> ls -l /volume1/homes/     
...
drwxrwxrwx    6 mario    users         4096 Jan 26 10:42 mario
...

Nachdem ich folgenden Befehl ausgeführt hatte, klappte es plötzlich:

$ chmod 755 /volume1/homes/mario

Hierbei handelt es sich um eine im Grunde gut gemeinte Sicherheitsvorkehrung auf Unix-Systemen. Denn wenn andere Benutzer den Public Key eines anderen Benutzers ersetzen könnten, könnten sie sich anschliessen unter dessen Kontext einloggen.

Siehe auch der Beitrag SSH and home directory permissions auf Stackexchange.

Hintergründe

Ein grosses Problem dieser Synology-Box ist es, dass auf ihr ein abgespecktes Linux läuft, welches einerseits die gängigsten Debug-Optionen nicht zur Verfügung stellt (bspw. ein sauberes Logging der Aktivitäten von sshd), andererseits über eine schier unüberschaubare verschachtelte Konfiguration verfügt.

sshd_config

Insgesamt habe ich auf der Kiste drei sshd_config Konfigurationsdateien gefunden:

  • /etc/ssh/sshd_config
  • /etc.defaults/ssh/sshd_config
  • /usr/syno/etc.defaults/ssh/sshd_config

Welche ist nun die richtige? Und welche bleibt auch bei einem Update oder Neustart mit meinen Konfigurationsanpassungen bestehen? Ich weiss es bis heute nicht.

sshd neu starten

Auch hierfür gibt es mehrere Möglichkeiten. Im Netz habe ich zwei Befehle gefunden:

  • # killall sshd
  • # /usr/syno/etc.defaults/rc.d/S95sshd.sh restart

Wenn ich diese Befehle ausgeführt habe, bin ich natürlich schnurstracks aus der SSH-Session geflogen — logisch. Doch bei der Verwendung von killall hat man sich soeben gerade vollständig vom NAS ausgesperrt.

Glücklicherweise gibt es über das Web-GUI des NAS die Möglichkeit, SSH wieder zu starten:

  1. Control Panel
  2. Terminal
  3. [x] Enable SSH service

Was ich zudem auch realisiert habe: Wenn ich SSH über das GUI neu starte, wird /etc/ssh/sshd_config neu eingelesen. Wenn ich es mit den Kommandozeilenbefehlen neu starte, wird die Konfigurationsdatei irgendwie nicht beachtet …

Verschachtelte Start-Scripts

Wie genau wird nun aber SSH gestartet? Die Synology-Ingenieure haben sich wohl gesagt: „Wieso einfach, wenn es auch kompliziert geht?“ und sich einige verschachtelte Scripts geleistet:

/usr/syno/etc.defaults/rc.d/S95sshd.sh liest einerseits /etc.defaults/rc.subr als auch /usr/syno/etc.defaults/rc.ssh.subr ein. Gestartet wird der SSH-Daemon dann aber, indem das Script /usr/syno/etc.defaults/rc.ssh aufgerufen wird. Dieses Script sourced das bereits erwähnte /usr/syno/etc.defaults/rc.ssh.subr erneut.

Konfigurationsdatei forcieren

Als mir das Debugging zu blöd wurde, habe ich mich entschieden, die Konfigurationsdatei ein für allemal in das eigentliche Startscript /usr/syno/etc.defaults/rc.ssh hartzukodieren:

...
$SSHD -f /etc/ssh/sshd_config
...

Debugging in syslog? Fehlanzeige

Wer denkt, dass einem folgende Zeilen beim Debugging in /etc/ssh/sshd_config weiterhelfen, liegt falsch:

...
SyslogFacility AUTH
LogLevel DEBUG
...

In /var/log/messages, der einzigen von zwei Log-Dateien in diesem Verzeichnis, welche bisher am heutigen Tag aktualisiert wurden, finden sich keine weiterführenden Infos, wieso sich der Benutzer mario nicht Schlüsseln einloggen darf.

Tags: , , , , , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Montag, 13. Januar 2014

Das PHP Error-Log von einem Cyon-Server täglich per E-Mail zusenden

Ein guter Web-Entwickler hält das PHP Error-Log seiner Web-Sites und -Applikationen stets im Auge. Ich persönlich habe mir zum Ziel gesetzt, dass nur ein leeres Log ein gutes Log ist. Dies bedeutet demzufolge, dass man auf Produktivsystemen sauberen Code ausliefert. Und sollten doch einmal Fehlermeldungen, Warnungen und Infos im PHP Error-Log auftauchen, gilt es diese zeitnah zu beheben.

Damit man eine Web-Präsenz, welche auf einem Cyon-Server mit SSH-Zugang läuft, überwachen kann, sind folgende Anpassungen nötig:

php.ini

Bei meinen Hostings befindet sich diese Konfigurationsdatei unter ~/etc/php_settings/default/php.ini. In dieser Datei sollten die folgenden Parameter gesetzt sein:

...
error_log = /home/%CYON-ACCOUNT%/var/log/php.err
...
error_reporting = E_ALL # Allenfalls auch & ~E_DEPRECATED
...

Dabei sollte man sicherstellen, dass das Verzeichnis /home/>benutzernamen>/var/log/ existiert und schreibbar ist.

mail-php-error-log.sh

Nachfolgendes Script sorgt dafür, dass der Inhalt der heutigen php.err per E-Mail an eine frei definierbare E-Mail-Adresse gesendet wird. Nach dem Versand wird die php.err kopiert und das Original danach gelöscht. Dem Dateinamen der Kopie wird dabei der aktuelle Tag des Jahres (1 bis 365) angehängt, womit wir eine Art automatisiertes logrotate durchführen:

#!/bin/sh

LOG="/home/%CYON-ACCOUNT%/var/log/php.err"

if [ ! -f "$LOG" ]
then
        echo "File '$LOG' not found"
        exit 1
fi

LINES=`cat "$LOG" | wc -l`

if [ $LINES -lt 1 ]
then
        exit 0
fi

#echo "Since log file is not empty ($LINES lines) I'm now posting its content to the webmaster"
cat "$LOG" | mail -s "php.err" logger@domain.tld
#echo "Would now be sending mail"

# Secret Sauce
DAYOFYEAR=$(date +%j)
cp "$LOG" "$LOG.$DAYOFYEAR"
rm "$LOG"

exit 0

Dieses Script habe ich in meinem Home-Folder abgelegt und mittels chmod 700 für meinen Benutzer ausführbar gemacht.

crontab

Schlussendlich richtet man sich noch einen Eintrag in crontab ein, damit das Script automatisiert einmal im Tag aufgerufen wird:

$ crontab -e

Der Inhalt dieser Datei lautet:

MAILTO="logger@domain.tld"
...
12 23 * * * /home/%CYON-ACCOUNT%/mail-php-error-log.sh

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. Dezember 2013

syslog-ng motzt über nicht konforme Konfigurationssyntax

Bei den gelegentlichen apt-get dist-upgrades auf meinem Linux-Server motzt syslog-ng bei jedem Neustart des Services über eine inkompatible Syntax von /etc/syslog-ng.conf:

WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode Please update it to use the syslog-ng 3.5 format at your time of convinience, compatibility mode can operate less efficiently in some cases. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file.;

Wie löst man dieses Problem? Ich bin folgendermassen vorgegangen:

  1. Zuerst passe ich die Zeichenkette in /etc/syslog-ng.conf an. Anstelle der Version 3.3 trage ich dort frech wie ich bin einfach probehalber mal folgendes ein:

    @version: 3.5
    ...
  2. Als nächstes prüfe ich, dass syslog-ng mit den restlichen Angaben in der Konfigurationsdatei einverstanden ist — sprich in der Datei keine Syntax-Fehler vorhanden sind:

    # syslog-ng --syntax-only

    Wird hier keine Meldung gemacht, ist alles in bester Ordnung.

  3. Schlussendlich startet man syslog-ng neu:

    /etc/init.d/syslog-ng restart

Und gut is!

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. November 2013

Finder-Eigenschaften von Dateien auf der Kommandozeile auslesen

Mit nachfolgendem bash-Script durchsuche ich einen Ordner mit über 700 Photos und gebe all diejenigen JPG-Dateien aus, welche im Finder die Farbe „Rot“ zugewiesen haben:

#!/bin/sh

MDLS=`which mdls`
ATTRIBUTE="kMDItemFSFinderFlags" # Color
VALUE=12 # Red

for FILE in *.JPG
do
	RETVAL=$($MDLS -name "$ATTRIBUTE" "$FILE" | cut -d "=" -f 2)
	
	if [ $RETVAL -eq $VALUE ]
	then
		echo $FILE
	fi
done

exit 0

Alle zutreffenden Dateien kopiere ich mit folgendem Script in den Unterordner Highlighted (das obige Script habe ich unter filter-highlighted.sh abgelegt):

#!/bin/sh

FILES=`./filter-highlighted.sh`

for FILE in $FILES
do
	cp "$FILE" "Highlighted/"
done

exit 0

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 9. November 2013

E-Mail-Adressen aus einer Textdatei auslesen und mit imapfilter in einen Unterordner verschieben

Seit ich ein Smartphone besitze, verschiebe ich mittels dem alle 5 Minuten per cron-Job auf meinem privaten Server laufenden imapfilter unwichtige E-Mails in Unterordner, damit ich mich auf die wesentlichen Mails konzentrieren kann.

Der grösste Unterordner in meinem privaten E-Mail-Account heisst „_UNPERSOENLICH“ und enthält all den Newsletter-Plunder, welchen man die Woche hindurch so zugeschickt erhält. Die imapfilter-Regel, welche die treffenden E-Mail-Absender herausfiltert und dorthin verschiebt, ist mittlerweile auf über 60 Zeilen (d.h. 60 Absenderadressen) angewachsen. In der imapfilter-Konfigurationsdatei sieht dies dann in etwa so aus:

...
messages = mbox.INBOX:contain_from('domain1.ch') +
           mbox.INBOX:contain_from('domain2.org') +
           mbox.INBOX:contain_from('user@domain3.com')
           ...
           mbox.INBOX:contain_from('userxy@domain112.com')
messages:move_messages(mbox['_UNPERSOENLICH'])
...

Heute habe ich mich dazu entschieden, diese E-Mail-Adressen aus der Konfigurationsdatei herauszulösen, in einer Textdatei zusammenzufassen (je eine E-Mail-Adresse pro Zeile) und dann imapfilter diese Textdatei einlesen zu lassen und die Absenderadressen in einer Schleife in meiner INBOX zu suchen und gegebenenfalls in den Unterordner zu verschieben.

Äusserst hilfreich war dabei die Hilfe, wie man Lua zu einem solchen Vorhaben bewegt (imapfilter setzt auf Lua auf): File Read In Lua?

Basierend auf dieser Antwort habe ich folgenden Code in meine imapfilter-Konfigurationsdatei aufgenommen:

...
function file_exists(file)
  local f = io.open(file, "rb")
  if f then f:close() end
  return f ~= nil
end

function lines_from(file)
  if not file_exists(file) then return {} end
  lines = {}
  for line in io.lines(file) do 
    lines[#lines + 1] = line
  end
  return lines
end
...
-- Unpersoenlich
local file = '../filters/private-unpersoenlich.txt'
local lines = lines_from(file)

for key,email in pairs(lines) do
--  print('line[' .. key .. ']', email)
  messages = mbox.INBOX:contain_from(email)
  messages:move_messages(mbox['_UNPERSOENLICH'])
end
...

Im Ordner oberhalb desjenigen Ordners, welcher die imapfilter-Konfigurationsdateien enthält (für jeden meiner Accounts existiert eine solche Konfigurationsdatei), gibt es nun einen Ordner filters, welcher momentan die Datei private-unpersoenlich.txt enthält.

Mit den obengenannten Funktionen und Konstrukten wird die Textdatei ausgelesen und in eine Lua-Tabelle (in anderen Programmiersprachen wohl als Array bezeichnet) gespeichert (lines_from(). Anschliessend gehe ich mit einem for-Loop durch die Tabelle, filtere den Absender (contain_from()) und verschiebe treffende E-Mail-Nachrichten in den Ordner „_UNPERSOENLICH“ (move_messages(mbox['_UNPERSOENLICH'])).

Tags: , , , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Montag, 4. November 2013

MySQL-Parameter mit Perconas Monitoring Plugins in Cacti überwachen

Wer seine MySQL-Installation mit Cacti überwachen möchte, sei Perconas Monitoring Plugins empfohlen. Die Datei (zum Zeitpunkt des Verfassens dieses Artikels war 1.0.5 aktuell) lädt man sich im Download-Bereich des Anbieters herunter.

$ cd /tmp
$ wget http://www.percona.com/redir/downloads/percona-monitoring-plugins/LATEST/percona-monitoring-plugins-1.0.5.tar.gz

Anschliessend entpackt man das Archiv:

$ tar xvzf percona-monitoring-plugins-1.0.5.tar.gz

Danach wechselt man in das cacti-Unterverzeichnis …

$ cd /tmp/percona-monitoring-plugins-1.0.5/cacti

… wo man folgenden Befehl ausführt:

cp -R . /var/www/cacti/

Dies kopiert alle nötigen Dateien (sprich: das ss_get_mysql_stats.php-Script) in das cacti-Root.

Anschliessend erstellt man sich unter MySQL einen Benutzer, welchen das Percona-Script verwenden wird, um die Parameter auszulesen:

GRANT SUPER, PROCESS ON *.* TO 'mysqlmon'@'localhost' IDENTIFIED BY "sikrit";
FLUSH PRIVILEGES;

Die Zugangsdaten erfasst man nun auch noch im Script ss_get_mysql_stats.php.

Anschliessend importiert man das XML-Template mit dem Namen cacti_host_template_percona_mysql_server_ht_0.8.6i-sver1.0.5.xml in cacti — dies geschieht über den Menupunkt Import Templates.

Zu guter letzt richte man sich einen neuen Host ein, gibt in das Adressfeld localhost ein und weist dem Host den Typ Percona MySQL Server HT zu. Anschliessend kann man die Graphen generieren.

Debugging

Bei Problemen hilft es, im Script folgende Zeile anzupassen …

...
$debug = TRUE;
...

… und die Kommandozeile, wie sie im cacti-Log auftaucht, in einer interaktiven Shell auszuführen.

ERROR 2013 (HY000): Lost connection to MySQL server at ‚reading initial communication packet‘, system error: 0

Diesem Fehler stand ich zu Beginn gegenüber. Folgende drei Massnahmen lösten das Problem schlussendlich:

  • In /etc/mysql/my.cnf muss die Zeile mit bind-address = ... auskommentiert und der MySQL-Server neu gestartet werden.
  • Dem MySQL-Benutzer mysqlmon muss in der Tabelle user in der Datenbank im Feld Host localhost eingetragen werden.
  • MySQL muss über localhost und nicht über 127.0.0.1 angesprochen werden.

RRD-Dateien werden nicht aktualisiert …

… obwohl das cacti-Log aufzeigt, dass das PHP-Script Werte zurückliefert? Nach einem Debug-Spagat hatte ich die Lösung gefunden. Im cacti-Log las ich etwas in der Form:

...
/usr/bin/rrdtool update /var/www/cacti/rra/mysql_sort_rows_999.rrd --template Sort_merge_passes:Sort_range:Sort_rows:Sort_scan 1383591127:0:522:13426:951
...

Ich führte den Befehl auf der Kommandozeile aus und sah mich mit folgender Fehlermeldung konfrontiert:

ERROR: /var/www/cacti/rra/mysql_sort_rows_999.rrd: illegal attempt to update using time 1383591127 when last update time is 1383594548 (minimum one second step)

Den Unix-Timestamp 1383590086 konvertierte ich mit Bordmitteln in ein lesbares Kalenderdatum und stellte fest, dass die Uhrzeit eine Stunde zurück lag. Ich hatte es also mit einem ganz klassischen Zeitzonen-Problem zu tun!

Um sicher zu gehen, startete ich in eine interaktive PHP-Session:

$ php -a
Interactive mode enabled

php > date_default_timezone_get();
PHP Warning:  date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in php shell code on line 1
PHP Stack trace:
PHP   1. {main}() php shell code:0
PHP   2. date_default_timezone_get() php shell code:1
php > 

Voila! Nachdem ich in der Datei /etc/php5/cli/php.ini folgende Information eingefügt hatte …

...
date.timezone = Europe/Zurich
...

… klappte es plötzlich mit den Updates.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Installing mod_bwshare on Debian Linux running Apache 2.0.x

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

Recently, I noticed msnbot was spamming my whole upload bandwidth because it seemed to create a complete dump of my photo gallery – several image requests within a minute! After some googling I discovered several Apache modules which promise to get rid of such bots running amok (although there are some concerns about artificially prolonging download times for leechers – beware!). I finally decided to go on with mod_bwshare. In a temporary „dust of war“, I got the wrong impression that I needed to upgrade to Apache 2.0.x to be able to get a precompiled .deb. Well, haha! There isn’t a debian package available right now. Well, okey, at least I’m running the newest Apache now, although I had to

apt-get remove apache
dpkg-reconfigure php4
dpkg-reconfigure php4-mysql
dpkg-reconfigure php4-curl
dpkg-reconfigure php4-imap
dpkg-reconfigure php4-gd

to get back to my „touched working system“ and make PHP aware of Apache 2. Be aware: Everything starts with untouched config files, so make sure you enable error logging in PHP again. Especially if you’re a web-dev like I am, you know about usefulness of

error_reporting = E_ALL

Okey, now straight back to the task. Since all this stuff is open source, we could at least give it a try with compiling and stuff (honestly, I just now enough about compiling to completly havoc a system, but I was a lucky guy in this case). So download the source files:

cd /tmp
wget http://www.topology.org/src/bwshare/bwshare-0.1.3.zip
unzip bwshare-0.1.3.zip

So, there we had’em now, hundreds of lines of codes. As stated on the developers homepage itself, running

cd src/modules/bwshare
apxs2 -c mod_bwshare.c
apxs2 -i mod_bwshare.la

Should do the trick. Nada, first we needed the developer package:

apt-get install apache2-dev

Once again:

apxs2 -c mod_bwshare.c
apxs2 -i mod_bwshare.la

A lot of warnings were displayed, but finally, I read

...
chmod 644 /usr/lib/apache2/modules/mod_bwshare.so

After having succesfully compiled mod_bwshare, I had to create two text-files in /etc/apache2/mods-available/

bwshare.load
bwshare.conf

and pasted the following contents:

LoadModule bwshare_module /usr/lib/apache2/modules/mod_bwshare.so
# Some bandwidth control parameters.
BW_tx1cred_rate         2
BW_tx1debt_max          10
BW_tx2cred_rate         1000
BW_tx2debt_max          1000000

<Location /bwshare-info>
SetHandler bwshare-info
</Location>

<Location /bwshare-trace>
SetHandler bwshare-trace
</Location>
</IfModule>

That was it (if you got that far, you surely know now what comes next – putting symlinks in mods-enabled/ and doing a

apache2ctl graceful

(Thanks to our solaris master Aeschlimann at the University for the graceful hint some time ago – greetz).

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen