Unknown Authz provider: from

Then you probably made a mistake replacing:

allow from all 

with

Require all granted

And just replaced allow with Require and not the complete directive, like:

Require from all

Then its time for a double facepalm :)

Starting with Apache and mod_proxy, i ended up with a plain node solution, which i really like.

Let’s take a quick look on some different approaches out there:

—1—

Using apache on port 80 as a proxy

ProxyPass /nodeurls/ http://localhost:9000/
ProxyPassReverse /nodeurls/ http://localhost:9000/

via stackoverflow

— no websockets
++ probably the easiest way to integrate with your running AMPP-stack

—2—

Using a node.js app on port 80 as a Wrapper for other node apps.

express.createServer()
  .use(express.vhost('hostname1.com', require('/path/to/hostname1').app)
  .use(express.vhost('hostname2.com', require('/path/to/hostname2').app)
.listen(80)

via stackoverflow

++ you can use websockets on port 80
— apps crash/restart/stop globally
–what about your apache or the like?

—3—

Using node.js with node-http-proxy on port 80

var http = require('http')
, httpProxy = require('http-proxy');

httpProxy.createServer({
  hostnameOnly: true,
  router: {
    //web-development.cc
    'www.my-domain.com': '127.0.0.1:3001',
    'www.my-other-domain.de' : '127.0.0.1:3002'
  }
}).listen(80);

++ proxy websockets to any port
— you might need to move your old web server to another port

The really cool thing about using node-http-proxy is its capability of proxying websockets.
So you can have your apps running independtly on different ports while serving everything to the user over port 80 and use stuff like socket.io.

Since i’m new to node.js and miles away from beeing a admin, any feedback is highly appreciated :)

Cannot allocate memory at ...

So first i suspected mongodb to use up loads of memory as top showed.

But after some recherche work i learned mongodb only -seems- to use a lot of memory.
see here and here and here
The actual usage was around 20mb RAM, so mongodb was innocent.

The true RAM monsters were some apache and php-fpm zombies, but thats another story.

While suspecting mongodb i thought about outsourcing the mongodb and i found a free and sufficient offer in mongolab.
My interests were on and i gave it a try.
The free version has a limit for up to 240MB storage and since my app is just a small counter it should last for some time.

The registration was easy, creation of the database aswell and the administration panel is also pretty cool and informative.

Then create a user and migrate:

First get my data from the vserver on the vserver:

 mongodump --host 127.0.0.1

Then fetch it to my local machine:

 scp -r me@vserver.de:/var/www/vhosts/verrueckte/dump/mongodumpdata .

Ups i didnt had no mongo client on my local machine, go get it:

 sudo apt-get install mongodb-clients

Now connect to the mongolab via your console

 mongo db123xyz.mongolab.com:12345/thedb -u <user> -p <pw>

Hey works, great!
Alright see you later.

 > exit;

Now import the dumps to continue the counter there were i stopped.

 cd mongodumpdata
 mongorestore -h db123xyz.mongolab.com:12345 -d thedb -u -p .

Good!

Then teach the php app the new connection:

 $this->host = 'mongodb://user:pw@db123xyz.mongolab.com:12345/thedb';
 new mongo($this->host);

There you go! The counter is storing its stuff to the mongolab database.
And i can stop the mongod on my machine and free some memory.

 ps aux | grep mongodb
 kill <PID>

choose your package: http://debian-multimedia.org/pool/main/l/lame/

wget http://debian-multimedia.org/pool/main/l/lame/lame_3.98.2-0.4_i386.deb
dpkg -i lame_3.98.2-0.4_i386.deb

yay!

FPM installieren geht so, wie er es dort beschreibt:

Allerdings in der conf den Port nicht als String, sondern numeric:

server.modules   += ( "mod_fastcgi" )

## Start an FastCGI server for php (needs the php5-cgi package)
fastcgi.server    = ( ".php" =>
        (
"localhost" =>
        (
                "host" => "127.0.0.1",
                "port" => 9000
        ))
)

Bleibt noch das Problem mit dem APC Konflikt, falls da jemand eine Lösung weiß, nur her damit.

Man, das war ein kampf ;)
Mal sehen wie lang das hält…

git prompt – GIT repository status direkt im shell prompt.

nützlich und schön bunt.

Also aufgemacht und es installiert:
Munin ist Server-Client mäßig aufgebaut, ich installiere der Einfachkeit halber mal Server und Client (Node) auf der selben Maschine.
Für Debian Lenny geht das ganz einfach über apt-get:

apt-get install munin munin-node

So nun noch das Webinterface umlegen: ich mache dafür eine eigene Subdomain bei einem meiner vHosts über Plesk.
zB munin.nerdpress.org (nein, die url gibts in echt nicht)

jetzt muss noch das www Verzeichnis, welches Munin generiert umkopiert werden in das Subdomain Verzeichnis:

cp -r /var/www/munin/* /var/www/vhosts/nerdpress/subdomains/munin/httpdocs

Wichtig ist noch die Besitzer richtig zu setzen:

chown -R munin:munin /var/www/vhosts/nerdpress/subdomains/munin/httpdocs

Das Verzeichnis sollte man dann noch über .htaccess Passwort schützen.

Nun noch Munin beibringen das sein www Verzeichnis woanders ist, dafür muss man in die munin.conf

joe /etc/munin/munin.conf:

und folgendes ändern:

htmldir /var/www/vhosts/nerdpress.org/subdomains/munin/httpdocs

Und wenn man schonmal da ist, kann man auch direkt seinen Server registrieren:

[munin.nerdpress.org]
address 127.0.0.1
use_node_name yes

Weiter gehts mit dem Node, dieser will auch noch konfiguriert sein:

joe /etc/munin/munin-node.conf

Dort den host_name anpassen:

host_name munin.nerdpress.org

Soweit so gut. Nun sieht man aber noch nichts. Dafür muss man erstmal die Plugins, die man braucht aktivieren.
Dies geschieht durch einen symlink:

ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/apache_accesses
ln -s /usr/share/munin/plugins/memory /etc/munin/plugins/memory

Damit sind das Plugin, was den RAM monitored und das für die Apache Accesses “installiert”.

Jetzt noch den Node restarten

/etc/init.d/munin-node restart

und ein wenig warten, dann sollte man unter munin.nerdpress.org die ersten Graphen sehen.

Aber nichts funktioniert ja auf Anhieb ohne Probleme, so auch hier:
Die System Plugin Graphen für Memory, Plattenplatz und CPU funktionieren, die Apache Plugins produzieren jedoch einen leeren Graph.

Warum dies?
Mit Googles Hilfe dann ein paar Debug Schritte vorgenommen:

munin-run apache_accesses

Dies sagt: accesses80.value U

munin-node-configure --suggest | grep apache

sagt:
Got junk from apache_accesses:

Des Rätsels Lösung ist dem Apache “sprechen beibringen”, wie hier und hier beschrieben.

Also die /etc/apache2/apache2.conf editiert und folgenden Block so umgeschrieben, wichtig ist dabei das ExtendedStatus On:

<IfModule mod_status.c>
    #
    # Allow server status reports generated by mod_status,
    # with the URL of http://servername/server-status
    # Change the ".example.com" to match your domain to enable.
    #
    ExtendedStatus On
    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    </Location>
</IfModule>
 

Noch den Apache restarten

/etc/init.d/apache2 restart

und siehe da auch die Apache Graphen werden gefüllt.

Ich hoffe Plesk läßt die Apache Konfiguration so stehen, aber bisher siehts so aus.

Mal sehen was man damit noch alles anstellen kann.

tail -f /var/log/apache2/error_log

Bekommt man nämlich so einen Fehler in der error_log:

ALERT - configured POST variable limit exceeded - dropped variable ...

… bleibt die Seite meistens ohne Fehlerausgabe trotz E_ALL und es passieren komische Dinge.
Dann kann man schonmal eine ganze Weile damit verbringen ganz woanders zu suchen.
Mit offenem error_log wäre das nicht passiert ;).

Die Lösung war übrigens im suhosin des Apaches zu finden: Ein Hoch auf unseren Admin Daniel.
Einfach in der php.ini oder suhosin.ini die Werte anpassen und man kann wieder riesige Formulare absenden.

[suhosin]
suhosin.post.max_vars = 2000
suhosin.request.max_vars = 1000

Ach ja und natürlich den Apache neustarten.

This problem is also valid for the ASUS UL30A. The touchpad is seen as an “ImPS/2 Logitech Wheel Mouse”. See in dmesg and by the command “xinput list”. I am using Ubuntu 9.10.

To disable the touchpad the following command can be used:

xinput set-int-prop “ImPS/2 Logitech Wheel Mouse” “Device Enabled” 8 0

To enable use:

xinput set-int-prop “ImPS/2 Logitech Wheel Mouse” “Device Enabled” 8 1

To make the F9 working I did the following:

1. As the F9 does not generate a keycode but an acpi event you cannot assign just a keycode to a script. So I first checked the generated event hotkey code using:
sudo acpi_listen
and pressed F9. This gives 0000006b as event hotkey code.
2. In /etc/acpi/events there is an asus-touchpad event file. This is using the wrong code so I changed it.
3. The script /etc/acpi/assus-touchpad.sh is not correct for this touchpad so I changed it (see attached script)
4. Now send the acpid a SIGHUP signal (or reboot) and the F9 button toggles your touchpad an or off.

Danach kann man via FN + F9 wieder wie gewohnt das Touchpad an- und abschalten.

Zunächst einmal Plesk auf neuesten Stand bringen über den Updater von Plesk.

Dann das Debian dist upgrade:
wie hier beschrieben:
Die Liste mit den Quell-Paketen ändern:

# new lenny packages.
deb http://ftp2.de.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

# source packages.
deb-src http://ftp2.de.debian.org/debian/ lenny main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

# volatile sources
deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free

Dann upgraden

apt-get update
apt-get dist-upgrade

Das wars schon und da war der Lenny, PHP war auch neu und die Seiten liefen alle noch.
Soweit so gut. Doch nun die Probleme:

FTP tats nicht mehr. Liegt wohl daran das ich noch den Plesk für Etch drauf hatte und das neue ProFTP damit nich kompatibel ist.

Außer dem gibt Plesk einen SSL Error und kann keine Keys mehr beziehen.

Cannot retrieve license key: SSL connect error

Ein bißchen gegooglet und zum Schluß gekommen Plesk neu zu installieren.
Also Plesk deinstalliert.

apt-get remove psa
apt-get remove psa-api
apt-get remove plesk-base
apt-get remove plesk-skins

Plesk wieder installiert:

apt-get install psa

Plesk gestartet:

/etc/init.d/psa start

Da Plesk nun aus lenny Packeten stammt, stimmte das jetzt auch wieder überein und siehe da:
Ftp tuts wieder!

Doch es gibt immer noch den SSL Error.

Dann das hier gefunden:
http://kb.parallels.com/en/6096
Aha! libCurl ist inkompatibel und muss downgegradet werden

Mal nachgeschaut:

cd /var/cache/apt/archives/

Und die Version ist also noch im Cache.
Dann downgraden:

dpkg -i libcurl3_7.15.5-1etch3_i386.deb

Hurra es funktioniert!
Der Key wird geupdatet.

Jetzt sagt da PHP Curl aber nö:

Unable to load dynamic library ‘/usr/lib/php5/20060613+lfs/curl.so

Also Curl wieder upgegradet:

apt-get install php5-curl
dpkg -i libcurl3_7.18.2-8lenny3_i386.deb

Dann ging auch das wieder.

Wahrscheinlich muss ich dieses Hin und Her jetzt jedes Mal machen wenn Plesk einen neuen Key braucht.
Das ist ein wenig nervig, aber hoffen wir mal auf ein Plesk Update, was das behebt.

Abschließend muss ich noch sagen, dass wegen der Plesk Neuinstallation noch ein paar PHP Einstellungen neu gesetzt werden mußten
wie zB safemode für die cli ausmachen usw, aber nix gravierendes.

Natürlich ohne Gewähr und ja, ich hab natürlich fleißig vorher und mittendrin gebackupt.