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>

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.

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.

Unter Server -> Mail gibt es eine “SPF spam protection”, also die mal ausprobiert:
– SPF Filter angeschaltet

– folgende Einstellungen gemacht:
SPF checking Mode: Only create Received-SPF headers, never block
(war doch etwas mißtrauisch, deswegen erstmal gucken was dabei raus kommt)
Nun werden die Mails mit einem zusätzlichem Header ausgestattet, den man local dann filtern kann.
Dazu mehr hier
– SPF local rules: include:spf.trusted-forwarder.org
– SPF guess rules: a/24 mx/24 ptr
Alles von hier übernommen: http://www.saout.de/misc/spf/

… und gespeichert

Dann einen Filter für den Thunderbird gemacht um die vermeintlichen Spam Mails direkt in den Junk Ordner zu verschieben.
Dazu muss man den neuen Header Thunderbird beibringen, das geht über die -Customize- Option.
Filter gesetzt auf Received-SPF: fail
und fertig

Resultat ist jetzt nicht berauschend: grob geschätzt von 100 mails gehen damit 10 in den Junk Ordner.
Nicht optimal aber immerhin schonmal ein bißchen besser für relativ wenig Aufwand.

Wenn da jemand noch ein Tip hat, immer her damit.