Kilo Mike - Ich blocke….

Als doch etwas verwöhnter, ehemaliger Confixx-User ist der Umstieg auf Plesk ein großer Schritt, der viel Gewöhnung bedeutet. Neben vielen Vorteilen, die Plesk zweifelsohne bietet, ist ein großer Nachteil, dass man keine httpd-Einträge mehr komfortabel über eine GUI machen muss. Hier ist wieder Handarbeit angesagt..

Ich stand vor dem Problem des open_basedir, welches angepasst werden muss. Per .htaccess ist dies nicht möglich, das verändern der httpd.conf ist nur von temporärer Dauer.. Also folgendes:

Im Verzeichnis der jeweiligen Domain gibt es einen conf-Ordner, z.Bsp.:

Domain: kilomike.de -> /var/www/vhosts/kilomike.de/conf/

Subdomain: www.kilomike.de ->/var/www/vhosts/kilomike.de/subdomains/www/conf/

mittels

touch vhost.conf

eine Datei anlegen. Diese mit dem Editor entsprechend befüllen, mein Beispiel hier setzt z.B. das open_basedir und die maximale Filesize für Uploads fest:

vhost.conf        
<Directory /var/www/vhosts/sf-fotos.de/subdomains/www/httpdocs>
php_admin_value open_basedir "/var/www/vhosts/sf-fotos.de/subdomains/www/httpdocs:/tmp"
php_admin_value post_max_size 500M
php_admin_value upload_max_filesize 500M
</Directory>

Nach dem Abspeichern muss dem Apapche nurnoch die Verwendung der neuen .conf angezeigt werden:

/usr/local/psa/admin/sbin/websrvmng -a

Dieser Befehl erstellt für alle Hosts die httpd-Einträge neu..

Ich bin seit einigen Tagen mitten im Umzug von meinem “alten” root-Server auf einen neuen, kleineren VServer. Leider klappt nicht alles so, wie es soll, vor allem Gallery2 macht Probleme.. Eine Hürde, vor der ich derzeit stehe ist, wie ich das System wieder auf Deutsch bekomme. In der Site-Administration sind alle Einstellungen auf Deutsch, trotzdem bleibt die Software stur bei englischer Kommunikation. Eine ssh-Ausgabe von

locale -a

brachte mich insofern weiter, dass nur C und POSIX aktiviert waren, nach kurzem

dpkg-reconfigure locale -plow

konnte ich dann auch diverse de_* UTF-8 aktivieren.. Und kurzum war die Gallerie/Gallery2 auch Deutsch…

Man(n) wächst ja an seinen Herausforderungen… So auch diesmal.

Die Aufgabenstellung: Wir brauchen einen gaaaanz einfachen Proxy-Server, der (basierend auf einer Blacklist) nach Begriffen filtert. Kosten soll er natürlich nichts, udn einfach zu administrieren soll er auch sein..

Die Lösung: Und wieder einmal geht mein erster Gedanke zu Linux, im Detail Debian. Durch die guten Erfahrungen mit Debian 4.0 in Verbindung mit VMWare Server bestärkt, war das Basissystem (einmal ohne Allem) schnell aufgesetzt (Zeitaufwand < 30 Minuten). Nachdem ich den Midnightcommander, HTOP und SSH

apt-get install mc ssh htop

installiert hatte, ging es auch mittels wget ans saugen von Webmin, der netten und benutzerfreundlichen Oberfläche für Linux. Ein kurzes

dpkg -i webmin_all_1.420.deb

und händisches Installieren der abhängigen Bibliotheken mittels apt, konnte ich über https://IP:10000 auf Webmin zugreifen. Bisher hat der ganze Eingriff nichtmal 45 Minuten gedauert.

Im Webmin versteckt sich unter dem Menüpunkt “Unused Modules” der “Squid Proxy Server”, sympathischerweise findet man gleich einen Link zum vollautomatischen Installieren und 3-4 Sekunden später ist er fertig.. Der Squid.

Die Standard-Zugriffskontrollen (ACL) “Safe Ports” und “SSL Ports” sind (auf deutsch gesagt) für den Arsch und können gelöscht werden.. Wichtig ist, dass die ACL “all” und “Apache” nicht gelöscht werden, aus Vorsichtsgründen habe ich mich (Lernen macht schlau und aus Fehlern wird man klug) nur von den ACLs “Safe Ports” und “SSL-Ports” getrennt und aber alle anderen ACL deaktiviert…

Dann wurden 2 neue ACL angelegt:

Bad_Words: “URL_Regexp” Hier kommen zeilenweise alle bösen Stichworte rein, bei denen die nette “Access denied”-Meldung kommen soll.

Bad_URL: “Webserver_Hostname” Hier kommen zeilenweise alle Hostnamen rein, auf die nicht zugegriffen werden soll.

Der Unterschied zwischen “URL_Regexp” und “URL_Path_Regexp” ist ganz einfach: “URL_Regexp” sucht in der gesammten Adresszeile nach den bösen Wörtern, “URL_Path_Regexp” lässt von der Suche die Domain außen vor und kümmert sich nur um alles hinter der TLD (.de, .com,…).

Diese ACLS werden jetzt noch wie folgt aktiviert:

Bad Words - deny

Bad_URL - deny

all - grant

Nach Speichern und setzen des Proxys am entsprechenden Client auf den (Standard-)Port 3128 läuft alles wie am Schnürchen, in nichtmal 60 Minuten wurde ein (zugegeben einfacher) Proxy-Server aufgesetzt..

Munin gefällt mir immer mehr…

Meine Root-Server habe ich jetzt so konfiguriert, dass er zusätzlich zu den Informationen zu seinem System auch noch die Informationen eines Remote-PC, in diesem Fall meines kleinen Debian-Servers zu Hause, aufbereitet. Verbunden sind die beiden über ein VPN, natürlich ist hier OVPN im Einsatz… Wie sieht die Konfiguration nun in der Praxis aus:

Auf dem “Master”-Muninknoten fügt man in die /etc/munin/munin.conf einfach unter dem Abschnitt für localhost folgendes ein:

[Remote-PC.Remote-Domain]

adresse IP

Auf dem Remote-PC sollte dann in der /etc/munin/munin-node.conf folgendes angefügt werden:

allow ^###\.###\.###\###$

Hierbei stehen die #-Triple immer für ein Oktett/Abschnitt der IP-Adresse.

Nach einem kurzen /etc/init.d/munin-node restart auf beiden Kisten läuft’s..

Hallo,

wieder mal durch einen Zufall bin ich auf ein nettes, natürlich Open Source, Tool gestoßen. Munin ermöglich eine übersichtlich und grafisch aufbereitete Monitoring-Lösung für Debian/Linux.

Einfach installiert mit apt-get install munin ist es binnen weniger Sekunden eingerichtet. Der neu gestartete Prozess munin-node ist mittels htop zu sehen. Alle 5 Minuten will dieser Prozess nun unter /var/www/munin seine Files ablegen. Dieser Pfad muss dann aber über die Datei /etc/munin/munin.conf unter htmldir angepasst werden, wenn man Confixx verwendet. Hier lautet der korrekte Pfad /var/www/confixx/html/munin, welches natürlich angelegt werden muss (mkdir). Das neu angelegte Verzeichnis wird mittels chown munin:munin und chmod 755 mit entsprechenden Rechten versehen. Sollten dann im Logfile unter /var/log/munin/munin-html.log Fehlermeldungen:

Mai 27 20:00:10 - Starting munin-html, checking lock
Mai 27 20:00:10 - could not copy style.css into htmldir
Mai 27 20:00:10 - could not copy logo.png into htmldir
Mai 27 20:00:10 - could not copy definitions.html into htmldir
Mai 27 20:00:10 - processing domain: localdomain
Mai 27 20:00:10 - processing node: localhost.localdomain
Mai 27 20:00:10 - processing service: cpu
stehen hilft ein kurzes chmod 755 auf /var/www/confixx und nach ein paar Minuten funktioniert alles.

Hallo,

ich versuche derzeit das hwdVideoShare Modul für Joomla 1.5 zum Laufen zu bekommen. Die Umgebung ist mal wieder Debian in der Version 3.1.

Das Modul ermöglicht es eine Art Video-Plattform hinzusetzen. Natürlich braucht es auf dem Server eine lokale Umwandlungsmöglickeit, ganz so weit ist PHP nun auch wieder nicht…

So wird u.a., neben FFMPEG, das FLVTool2 benötigt. Bei der Recherche nach der einfachsten Installation stieß ich auf einige Problemberichte des Tools, und einen Workaround:

FLVTool2 broken - Het bijstere spoor

Er empfielt den Einsatz des FLVTool++, einer Weiterentwicklung. Die Installation unter Debian ist auch hübsch einfach:

To make FLV’s coming from flash streaming servers (FCS/FMS/Red5) properly work as a progressive download, it’s often required to use a tool to inject ‘missing’ meta-data.

Up until now I used FLVTool2 for this, but it seems to load the entire FLV into memory (badd!), and now I’m getting nasty errors as well..

ERROR: EOFError ERROR: /usr/local/lib/site_ruby/1.8/flv/amf_string_buffer.rb:37:in `read’ ERROR: /usr/local/lib/site_ruby/1.8/flv/amf_string_buffer.rb:243:in `read__STRING’ ERROR: /usr/local/lib/site_ruby/1.8/flv/audio_tag.rb:56:in `read_header’ ERROR: /usr/local/lib/site_ruby/1.8/flv/audio_tag.rb:47:in `after_initialize’ ERROR: /usr/local/lib/site_ruby/1.8/flv/tag.rb:56:in `initialize’ ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:447:in `new’ ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:447:in `read_tags’ ERROR: /usr/local/lib/site_ruby/1.8/flv/stream.rb:58:in `initialize’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:272:in `new’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:272:in `open_stream’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:238:in `process_files’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:225:in `each’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:225:in `process_files’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2/base.rb:44:in `execute!’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2.rb:168:in `execute!’ ERROR: /usr/local/lib/site_ruby/1.8/flvtool2.rb:228 ERROR: /usr/bin/flvtool2:2:in `require’ ERROR: /usr/bin/flvtool2:2

I wanted to try out FLVTool++ anyway, as it seems like a much more scalable solution.. This is how its installed on debian:

Grab the source:
wget http://rcdn.org:8080/images/4/44/Flvtool%2B%2B.tar.bz2

Unpack
tar xfvj Flvtool++.tar.bz2

Make sure you have a compiler installed (as root).
apt-get install build-essential

Compiling
make

AArrghh! It doesn’t compile :(.
This is the error it gave me:
g++ -O2 -c -Wall -D_FILE_OFFSET_BITS=64 flvtool.cpp -o flvtool.o AMF.h:35: error: invalid pure specifier (only `= 0′ is allowed) before ‘;’ token flvtool.cpp: In function ‘int main(int, char**)’:
flvtool.cpp:192: warning: too many arguments for format
make: *** [flvtool.o] Error 1

Ok, lets dig into this code a bit.. the errors seems to give a few useful hints..

First thing I did was go to line 35 in AMF.h and change:

virtual std::ostream& operator << (std::ostream& os) const = NULL;

into:

virtual std::ostream& operator << (std::ostream& os) const = 0;

Next, open flvtool.cpp (line 192) and change:

fprintf(stderr, “usage:\n”, argv[0]);

Into:

fprintf(stderr, “usage:\n”);

Now, for some reason you also need to manually create the bin/ directory in your source directory, after that you can start compiling again.

mkdir bin
make

Success! Your bin/ directory will now contain the flvtool++ binary.

/bin/flvtool++
#outputs: flvtool++ version 1640 2007/05/24 14:39:18 usage:
flvtool++

Und noch ein klasse Tutorial: Wie gehe ich vor, wenn ich unter Debian einen Webserver einrichten will/muss…

Hier der Link

Der Text von http://www.tim-bormann.de

Vorbereitungen Installation Debian Etch

Exkurs: Vorbemerkungen zu Debian Etch und APT vs APTITUDE:
Der bisherige Standard-Paketmnager unter Debian Linux war APT. Mit der Veröffentlichung von Debian Etch wird Aptitude das empfohlene Werkzeug zur Paketverwaltung! In diesem Debian Etch Tutorial nutze ich APT, da Meinung mein nach APT schneller ist und ich die Vorteile von APTITUDE, das einfach auf APT aufsetzt, gar nicht nutze oder benötige. Wer lieber Aptitude nutzen will kann im Folgendem ‘apt-get’ in der Regel durch ‘aptitude’ ersetzen.
Vielleicht für manche interessant: Aptitude lässt sich sowohl als Komandozeilenbefehl ausführen wie auch als Benutzeroberfläche.
Kleine Liste an Unterschieden zwischen APT vs APTITUDE:

• ‘aptitude purge’ statt ‘apt-get remove –purge’
• ‘aptitude install Deb1+ Deb2- Deb3_ Deb4=’ (1 install; 2 remove; 3 purge; 4 hold

[...]

Der vollständige Artikel kann unter Tim Bormanns Seite eingesehen werden..

VPN-Verbindungen sind schon eine tolle Sache. Ich habe auf mit deren HIlfe z.B. eine verschlüsselte Verbindung zwischen meinem Laptop und meinem PC zu Hause. Die Vorteile liegen auf der Hand: Sicherheit auf der einen, zum anderen spart man sich mit einem VPN die Mühe und das Risiko von Portweiterleitungen auf einem Router. (Ob man das jetzt als Vorteil von VPN-Verbindungen sieht, darüber lässt sich sicherlich streiten, für mich ist es einer!!)

Bei der Open Source Lösung OpenVPN hat man die Möglichkeit entweder mittels eines sog. PSK (Pre-Shared-Key = Passwort) oder über ein Zertifikat die Verbindung abzusichern. Da man sich bei einem PSK ein Passwort merken muss, entschie dich mich für die Zertifikatsbasierte Lösung. Obwohl ich keine Ahnung von Zertifikaten etc. habe, hat die Einrichtung klasse geklappt. Wieso? Ganz einfach. Unter Online-Tutorials fand ich 2 klasse Anleitungen!! Hier die Links

OpenSSL-Tutorial (wird vorab benötigt)
OpenVPN-Tutorial (Schritt 2)

Hallo.

Da stand ich doch vor einem kleinen Problem. Ich wollte auf meinem Debian den Lame Encoder installieren. Leider gibt es kein *.deb-Paket o.ä. Nach kurzer Recherche fand ich den Grund: Lame wird in Etch nicht mehr offiziell unterstützt. Nach vielen (Fehl-)Versuchen bin ich dann auf eine klasse Anleitung auf Howtoforge gestoßen, bei der es sich in einem Absatz um Lame handelt:

2 Installing LAME

LAME is an MPEG Audio Layer III (MP3) encoder. We need this so that our videos don’t lose their sound while they are being converted to FLV. Unfortunately, LAME isn’t available as an official Debian Etch package, so we must compile it manually. First, we install the tools we need for the compilation:

apt-get install build-essential

Then we go to the /tmp directory and download the latest LAME version from SourceForge, e.g. like this:

cd /tmp
wget http://mesh.dl.sourceforge.net/sourceforge/lame/lame-3.97.tar.gz

Then we unpack and compile LAME:

tar xvfz lame-3.97.tar.gz
cd lame-3.97
./configure –enable-shared –prefix=/usr
make
make install

Nachzulesen ist der gesamte Absatz natürlich nochmal unter Howtoforge.

Diese Seite ist nebenbei gesagt eine klasse Quelle für Informationen und Tutorials rund um alle Gebiete der Administration und der bunten Computerwelt.. Sehr Empfehlenswert..

So.. Bin grad am Putzen, meines 2-Wochen-alten Ubuntus… Ist halt alles schön neu und so..

Im Ubuntuusers-Forum bin ich da wieder auf einen tollen Artikel gestoßen..

[Howto] Nur benötigte Pakete behalten