sixserv blog

Habe gestern das erste testing Release von vBrowseFile veröffentlicht.

Installation(auszug aus der README-Datei):

- install HTTP_Download with pear
    For Debian you could do this with:
        # aptitude install php-pear
        # pear install --alldeps HTTP_Download

- Make sure .htaccess Files are used
    Change VHost setting: "AllowOverride All"

- Download vBroweFile Files to an webroot/vhost-root:
    Download an packaged vbf version.
    - or -
    Checkout the latest SVN version: (will create vbrowsefile/ directory)
    $ svn co svn://mount.at/geekosphere/vbrowsefile/trunk vbrowsefile/

- Make sure the following Directories are writeable by Webserver:
    /flatfiles
    /flatfiles/cache
    /flatfiles/cache/tracks
    /flatfiles/userquery
    /smarty/templates_c

- Go with your browser to the setup.php script:
    e.g. http://example.com/vbrowsefile/setup.php

- Now you could login, change configuration, add some virtual directories
  and create some normal users

Tagged: Coding, PHP, vbrowsefile

vBrowseFile uses a slightly modificated Version of HTTP_Download. HTTP_Download is a Pear-Module to send local Files to Browser:

Provides an interface to easily send hidden files or any arbitrary data to HTTP clients. HTTP_Download can gain its data from variables, files or stream resources.

It features:
- Basic caching capabilities
- Basic throttling mechanism
- On-the-fly gzip-compression
- Ranges (partial downloads and resuming)
- Delivery of on-the-fly generated archives through Archive_Tar and Archive_Zip
- Sending of PgSQL LOBs without the need to read all data in prior to sending

I added a ThrottleCallback functionality to HTTP_Download, a function that is executed after the BufferSize is transferred and the ThrottleDelay Time is waited. Modifications in HTTP/Download.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    var $throttleCallback = null;
    [...]
    function setThrottleCallback($callback)
    {
        $this->throttleCallback = $callback;
    }
    [...]
    function callThrottleCallback()
    {
        // execute callback
        if($this->throttleCallback != null)
        {
            $callback = $this->throttleCallback;
            $callback($this);
        }
    }
    [...]
    function sendChunk($chunk, $cType = null, $bound = null)
    {
    [...]
        // right after sleep is ex
        $this->callThrottleCallback();
    [...]
    }

This Callback could be used to track the download progress and to create a real bandwidth limitation. HTTP_Download supports a basic throttling mechanism to limit the bandwidth, but this only works for one connection, so e.g. you could limit 2 downloads to each 100 KiB/s but not all 2 downloads to each 50 KiB/s to limit the overall bandwidth to 100 KiB/s, instead it would be 200 KiB/s.
For this real bandwidth limiting you could use Apache modules like cband(seems not to work with php) or mod-bw, or you could use tc. Siyb from Geekosphere wrote an article about mod-bw: Limit Bandwidth per vHost in Apache2 (on Debian/Lenny)

Another possible way to limit the bandwidth is to implement it with HTTP_Download. The Theory is, to track all running downloads and change the BufferSize to := download limit * delay / active connections every seconds with the callback function from above.

More detailed:

• We generate a random connection id(i call it rcid) for the tracking file.
• ThrottleDelay is set to 1 seconds.
• BufferSize is set to 100 KiB * 1 Seconds * 1024 to setup a maximum speed of 100KiB/s.
• The Callback would now be executed every 1 Seconds:
  • create or overwrite our own rcid file with time() inside.
  • search for other rcid files and check there time-stamp. tracking files older then 5 seconds would be deleted.
  • count all rcid tracking files. e.g. 2 means there 2 open download connections.
  • change the BufferSize. e.g. for 2 open connections: (100 KiB * 1 Seconds * 1024) / 2

This would limit the overall bandwidth of all active connections to a maximum of 100 KiB/s with a delay of ~ <5 Seconds. Without any Apache Modules or other standalone traffic sharping tools. For small installations this should work with no problem but for bigger installations a more efficient traffic shaping tool would be more effective.

Example Implementation: Read the rest of this entry »

Tagged: Coding, Networking, PHP, vbrowsefile

Ich bin gerade dabei einen kleinen “Filebrowser” zu entwickeln. Dieser zeigt nicht zwangsläufig das reale Dateisystem an, sondern ist in der Lage mehrere real existierende Ordner zu einem virtuellen Ordner zusammen zu legen. Er ist nur zum einfachen herunterladen von Dateien gedacht, eine Upload-Funktion ist nicht geplant, eben sowenig wie das Umbenennen oder Löschen von Dateien. Zum Einsatz kommt PHP5, Smarty und das Pear-Paket HTML_Downloader.

siyb von Geekosphere(danke nochmal!) hat mir ein Redmine und Subversion eingerichtet.

Alles weitere wird es dann dort geben.

For our english speaking visitors:

Recently i began to develop a small Filebrowser. It does not necessarily show the real Filesystem but it can combine several directories to one virtual. The purpose is just to realise an easy way of downloading files, other features used in a common filemanager like the renaming or deleting of files are not planned. I use PHP5, Smarty and the Pear-Package HTTP_Download.

Thanks to siyb, now i can provide more informations at geekosphere wootcenter(redmine).

Tagged: Coding, PHP, vbrowsefile

Ich wollte von unterwegs aus den Status meines Heimservers abrufen können. Dabei ging es mir vorallem um die Temperatur von CPU, Mainboard und den Festplatten. Der auf sixserv.org laufende rbot(im Freenode idled der in #sixserv) soll auf Kommando den Status anzeigen. Soweit so gut. Ein kleines Ruby-Skript das auf dem Server zuhause läuft erfasst die Temperaturen per “sensors” und “hddtemp”. Der xinetd-Daemon konfigurierte ich daraufhin so das auf einen Port das Skript gebunden wird. Es erwartet bevor es die Daten übermittelt ein Passwort, einfach zum zusätzlichen Schutz auch wenn das vielleicht gar nicht nötig ist. Jemand der einen Portscan durchführt könnte eben so informationen zum System gelangen, die Passwortabfrage verhindert dies.

Zunächst zu dem Ruby-Script(z.B. /opt/botinfo.rb):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#!/usr/bin/ruby
 
i = Kernel.gets
if i.chomp != 'DASGEHEIMEPASSWORT' then
	# puts 'Wrong Password'
	exit
end
 
puts `uptime`.lstrip
 
# HDD Temps:
matches = `cat /proc/partitions`.scan /([s|h]d[a-z])/
matches.uniq!
matches.each do |disk|
	print "#{disk}: #{`hddtemp -n /dev/#{disk}`.chomp}.0*C (#{$1}GB) "
end
puts 
 
systemp = `sensors`
 
temp1 = systemp.scan /CPU Temp:    \+([0-9]+)\.0.C/
temp2 = systemp.scan /M\/B Temp:    \+([0-9]+)\.0.C/
 
puts "System: #{temp2[0]}.0*C #{temp2[1]}.0*C | CPUs: #{temp1[0]}.0*C #{temp1[1]}.0*C"

Hier muss natürlich sensors und hddtemp installiert sein, aber dieses Script kann praktisch alles mögliche an Informationen sammeln und ausgeben.
Die Konfiguration von xinetd gestaltet sich sehr einfach, in dem Verzeichnis /etc/xinetd.d einfach eine neue Datei für das Script erstellen(z.B. “botinfo”):

1
2
3
4
5
6
7
8
9
10
11

service botinfo
{
    disable         = no
    port            = 8888
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = apoc
    server          = /opt/botinfo.rb
    type            = unlisted
}

Den Port, User und den Skript Pfad entsprechend anpassen und xinetd neu starten. Mit netcat kann es man danach testen:

1
2
3
4
5

$ nc localhost 8888
DASGEHEIMEPASSWORT
18:40:35 up 3 days, 41 min,  4 users,  load average: 0.00, 0.02, 0.20
sda: 30.0*C (10GB) sdb: 29.0*C (10GB)
System: 39.0*C 38.0*C | CPUs: 37.0*C 36.0*C

Der Port muss ggf. vom Router geforwarded werden damit ein Entfernter Server darauf zugreifen kann. Auch ein dyndns ist hilfreich, sofern man über keine statische IP verfügt. Ein einfaches rbot-Plugin um diese Daten vom irc aus abzufragen sieht z.B. so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

require 'socket'
 
class BotinfoPlugin < Plugin
  def help(plugin, topic="")
    'info => return system information'
  end
 
  def info(m, params)
    sock = TCPSocket.new('heimserver.dyndns.org', 8888)
    sock.puts('DASGEHEIMEPASSWORT')
    m.reply sock.recv(1024)
    sock.close
  end
end
plugin = BotinfoPlugin.new
plugin.map 'info'

Die Daten können ebenfalls von einem PHP-Script aus abgefragt werden. Keines Beispiel:

1
2
3
4
5
6
7
8
9

<?php
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_connect($socket, "heimserver.dyndns.org", "8888");
 
$pass = "DASGEHEIMEPASSWORT\n\n";
socket_write($socket, $pass, strlen($pass));
 
echo socket_read($socket, 2048);
?>

Vielleicht findet das ja irgendjemand interessant

Tagged: hddtemp, irc, Linux, Networking, PHP, plugin, RBot, Ruby, sensors, xinetd

Bereits 2.6 machte einen großen Schritt, das Backend wurde umgestaltet, Versionierung der Artikel, Google Gears Unterstützung, zahlreiche Verbesserungen der Usability und sonstige Neuerungen machten Wordpress noch ein Stück mehr zu einen der besten Weblog-Applikationen die es gibt. Mit 2.7 setzen die Entwickler noch eins drauf, die Funktion zum Update eines Plugins direkt vom Backend aus war ja schon erster Schritt, doch mit 2.7 wird es möglich das gesamte Wordpress direkt vom Backend aus zu upgraden.

Core Update

Ebenfalls ist nun eine Plugin-Suche direkt im Backend integriert und neue Plugins können mit einem einzigen Klick installiert werden. Außerdem soll in Zukunft ein neuer Code-Editor für Theme und Plugin-Dateien, Syntax-Highlighting unterstützen, davon ist jedoch in der aktuellen Entwickler-Version noch nicht viel zu sehen.

Plugin Suche

Wordpress-Deutschland hat die Agenda der wohl erfolgreichsten Weblog-Software, Wordpress zusammengestellt. Außerdem gibt es ein Screencast vom neuen Backend.

Update: Am Design des Backends hat sich noch viel geändert aber es ist Grundlegend in die neue WP Version 2.7 eingegangen. Ich finde es ist sogar noch gelungener geworden wie die Entwickler-Version vermuten lies.

Tagged: backend, PHP, Wordpress

Das Sixserv Blog ist ein Multiuser-Blog(d.h. Mehrere Autoren verfassen Artikel), unter der Hauptdomain(sixserv.org) sollten alle Artikel angezeigt werden. Wir wollten allerdings zusätzliche Subdomains(z.B. apoc.sixserv.org) die die Artikel des jeweiligen Autors anzeigt. Besonders wichtig dabei war das es möglich ist pro Subdomain unterschiedliche Themes zu verwenden.
Als Grundlage für dieses Vorhaben verwendete ich das Wordpress-Plugin Domain-Mirror von Dave McAleavy. Ich ergänzte es um die Möglichkeit pro Domain einen Benutzer sowie Theme eingeben zu können:

Zeigt die neuen Einstellungsmöglichkeiten von Domain Mirror.

In der Apache Konfiguration des jeweiligen vHost der Subdomain genügt ein:

Alias /blog "<Wordpress-Pfad>"

Sofern kein Unterorder verwendet werden soll, äquivalent ein DocumentRoot mit Installations-Pfad. Dann kann man sich ebenfalls das anpassen der Rewrite Regeln in der .htaccess-Datei im Wordpress-Ordner sparen. Standardmäsig werden die Permalinks nämlich auf /index.php geroutet, was bei den Subdomains in unserem Fall nicht funktioniert, und entsprechend angepasst werden muss:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Wenn ohne Subdomain dann Standard Rewrite...
RewriteCond %{HTTP_HOST} ^sixserv.org$
RewriteRule . /index.php [L]

RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Hier mit Subdomain also mit /blog
RewriteCond %{HTTP_HOST} ^(^.*)\.sixserv.org$
RewriteRule . /blog/index.php [L]

Ihr könnt die erweiterte Version von Domain-Mirror hier herunterladen: domain-mirror1.1_patched1.zip [Patch-File für 1.1]

/
This is a customized Version of Domain-Mirror. I added the Feature to specifies the Theme and User per Domain-Entry. You can download the Patched Version of Domain Mirror 1.1 here: domain-mirror1.1_patched1.zip [Patch-File for 1.1]
\

Tagged: apache, PHP, plugin, Wordpress