Icecast und Apache auf Port 80 am vServer

  • Thread starter Thread starter Deleted member 13046
  • Start date Start date
D

Deleted member 13046

Guest
Hallo ich habe einen Debian Vserver für ein Webradio.
Darauf laufen Icsecast und das Auto DJ Airtime. Airtime braucht den Apache.

Nun ist das so das Icecast auf Port 8000 sendet was bei vielen Zuhörern für Probleme mit der Firewall sogt. Deshalb biegen alle Webradios den Stream auf Port 80 um.

Da wie gesagt der Apache ja auch auf Port 80 arbeitet kann ich also nicht einfach im Isecast den 80 angeben.
Viele arbeiten mit dem Apache Proxy. mod_proxy

Problem ist, ich bekomme es nicht hin den Proxy einzurichten.
mod_proxy ist installiert

Ich arbeite im Moment nur mit der IP (also rein IP-basiert) und hab kein Confixx oder so
Ich hab mich belesen und bin so vorgegangen:
in die /etc/apache2/sites-available/airtime-vhost (die vom Auto DJ)
ist folgendes eingetragen:
Code: 
<VirtualHost *:80>
      ServerName airtime.88.198.160.xyz
      #ServerAlias www.example.com

      ServerAdmin admin@xyz.fm

      DocumentRoot /usr/share/airtime/public
      DirectoryIndex index.php

      SetEnv APPLICATION_ENV "production"

      <Directory /usr/share/airtime/public>
              Options -Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              Allow from all
      </Directory>
</VirtualHost>
soweit alles gut

wenn ich jetzt den Proxy hinzufüge geht über Prot 80 garnichts mehr
Code: 
<VirtualHost *:80>
      ServerName airtime.88.198.160.xyz
      #ServerAlias www.example.com

      ServerAdmin admin@xyz.fm

      DocumentRoot /usr/share/airtime/public
      DirectoryIndex index.php

      SetEnv APPLICATION_ENV "production"

      <Directory /usr/share/airtime/public>
              Options -Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              Allow from all
      </Directory>
</VirtualHost> 

<VirtualHost 88.198.160.xyz:80>
      ServerName sound.88.198.160.xyz

<Proxy>
Order deny,allow
Allow from all
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://88.198.160.xyz:8000/
ProxyPassReverse / http://88.198.160.xyz:8000/
TransferLog /var/log/apache2/icecast-access.log
ErrorLog /var/log/apache2/icecast-error.log
CustomLog /var/log/apache2/icecast-access.log combined
LogLevel warn
ServerSignature On
</VirtualHost>

Was mache ich da falsch?
Oder gibt es noch eine andere bessere Möglichkeit den Stream Output auf dem vServer von Port 8000 auf Port 80 umzuleiten?

Besten Danke Gruß Haxley
 
ServerName sound.88.198.160.xyz
Click to expand...
Du versuchst eine Subdomain an eine IP zu hängen. Das ist technisch nicht möglich, entweder Domain oder IP aber beides gemischt geht nicht.

Es ist allerdings nicht empfehlenswert Apache als Reverse-Proxy zu verwenden da dieser bereits bei ein paar Dutzend Zuhörer in die Knie gehen kann, da er für jeden Benutzer einen eigenen Thread oder Prozess (je nach Konfiguration) laufen lässt.
Imho wäre es besser einen Nginx davor zu setzen welcher dann Apache und Icecast per reverse-proxy ausliefert.
 
Es ist allerdings nicht empfehlenswert Apache als Reverse-Proxy zu verwenden da dieser bereits bei ein paar Dutzend Zuhörer in die Knie gehen kann, da er für jeden Benutzer einen eigenen Thread oder Prozess (je nach Konfiguration) laufen lässt.
Click to expand...
Das dachte ich mir auch schon. Mit Nginx kenne ich mich nun garnicht aus, ist das nicht der russische Apache?

Geht es evtl. auch anders? Z.B. über einen richtigen Proxy wie squid? Wäre das möglich?

Wie machen die anderen Webradios das? Hat da einer Ahnung?

Danke Gruß Haxley
 
Haxley said:
Das dachte ich mir auch schon. Mit Nginx kenne ich mich nun garnicht aus, ist das nicht der russische Apache?

Geht es evtl. auch anders? Z.B. über einen richtigen Proxy wie squid? Wäre das möglich?
Click to expand...
Nun, Du musst nicht gleich mit Kanonen auf Spatzen schießen (Squid). Ein Wechsel des Webservers (Apache auf Nginx) will gut überlegt sein. deutlich einfacher in der Konfiguration wäre m.E. der reverse proxy pound. Den schaltest Du im Frontend auf port 80. Dahinter legst Du den Apache auf z.B. port 3128 und den Icecast auf 8000. Da pound wie andere reverse proxies auch virtual hosts beherrscht, kannst Du die Anfragen entsprechend steuern.

In der Konfig, sehe das im Falle von pound so aus (als Beispiel - Auszug):

Code: 
ListenHTTP
Address 192.168.1.101
Port 80
xHTTP 0 
LogLevel 2
End

Service
HeadRequire "Host:.*www.mydomain.com.*"
BackEnd
Address 192.168.1.101
Port 3128
End
End

Service
HeadRequire "Host:.*radio.mydomain.com.*"
BackEnd
Address 192.168.1.101
Port 8000
End
End
 
Last edited by a moderator:
ist das nicht der russische Apache?
Click to expand...
Das ist als ob du fragen würdest ob Linux das finnische Windows sei.
Nur weil beide eine ungefähr gleiche Aufgabenstellung lösen haben sie trotzdem nicht viel gemeinsam. Unter anderem ist Nginx hochskalierend durch event-orientierte Programmierung während Apache die Requests durch Threading oder Forking trennt. (Stimmt bei 2.4 mit mpm_event nicht mehr ganz aber naja)
Dein Vorteil hier wäre dass Engine-X keinerlei Probleme mit dem Beliefern von tausenden Clients gleichzeitig hat während verbreitete Apache-Konfigurationen auf gleicher Hardware bereits bei 100 gleichzeitigen Verbindungen aus dem letzten Loch pfeifen.

über einen richtigen Proxy wie squid? Wäre das möglich?
Click to expand...
Squid ist eher ein forward- denn ein reverse-Proxy, auch wenn er beides beherrscht. Nginx hingegen wurde als Webserver UND reverse-proxy entwickelt.
Eine Alternative wäre Varnish Cache (u.a. eingesetzt von Wikipedia und Steam) aber auch dieser betreibt multi-threading und ist somit weder gegen Slowloris-ähnliche Angriffe noch gegen das c10k Problem wirklich gefeit.
Ausserdem ist der Cache ne absolute Katastrophe in Bezug auf Streaming und grosse Downloads.
Andere Lösungen wären zB auch haProxy oder Apache Trafficserver.

Wie machen die anderen Webradios das? Hat da einer Ahnung?
Click to expand...
Teils über unterschiedliche IP's, teils über reverse proxies.
 
So ich habe pound install.

config:
Code: 
## redirect all requests on port 8080 ("ListenHTTP") to the local webserver (see "Service" below):
ListenHTTP
	Address 88.198.xxx.xx1
	Port 80
 	RewriteLocation 0
        RewriteDestination 0
	xHTTP 0 
	LogLevel 2
End

	Service
		HeadRequire "Host:.*www.mysound.fm.*"
		BackEnd
			Address 88.198.xxx.xx0
			Port 3128
		End
	End

	Service
		HeadRequire "Host:.*radio.mysound.fm.*"
		BackEnd
			Address 88.198.xxx.xx0
			Port 8000
		End
	End
Leider startet er nicht und es kommt die Fehlermeldung:
pound: HTTP socket bind 88.198.xxx.xx1:80: Address already in use - aborted
Click to expand...
Ich denk das das der Apache ist der mit *:80 auch an der zweiten IP lauscht.
Im Apache steht unter /etc/apache2/sites-available/airtime-vhost
Code: 
<VirtualHost *:80>
      ServerName 88.198.xxx.xx0
      #ServerAlias www.example.com

      ServerAdmin admin@xyz.fm

      DocumentRoot /usr/share/airtime/public
      DirectoryIndex index.php

      SetEnv APPLICATION_ENV "production"

      <Directory /usr/share/airtime/public>
              Options -Indexes FollowSymLinks MultiViews
              AllowOverride All
              Order allow,deny
              Allow from all
      </Directory>
</VirtualHost>
durch das *:80 wird doch meine zweite IP mit anggesprochen oder? Ich hab leider keine Ahnung wie ich den Apache auf eine IP festzurre.
verwende ich:
Code: 
<VirtualHost 88.198.xxx.xx0:80>
Bringt Apache eine Fehlermeldung:
[warn] NameVirtualHost *:80 has no VirtualHosts
Click to expand...

Was muss ich da machen? Die Httpd.conf ist übrigens leer.
Danke nochmal!
 
Haxley said:
... Was muss ich da machen? Die Httpd.conf ist übrigens leer.
Danke nochmal!
Click to expand...
Entschuldige meinen Sarkasmus ... Was Du noch tun musst? MITDENKEN! Sorry, nimm's mir nicht übel aber Du solltest besser keinen Server im Internet betreiben.

So nun zur Sache:

1) Bevor Du pound startest, wäre es vermutlich zweckmäßig den Apache zu beenden, der ja bis dato ebenfalls noch auf Port 80 lauscht. Wenn man es ganz genau machen will, wird zuerst der Apache neu konfiguriert und gestartet und dann der pound, sonst laufen u.U. die ersten Requests ins Leere. Aber das könnte man unter dem Punkt "In Schönheit sterben" verbuchen.

2) https://serversupportforum.de/threads/warn-namevirtualhost-80-has-no-virtualhosts.1125/

3) Du lässt den Apache bisher inkl. der vHosts fleißig weiter auf Port 80 lauschen. Das könnte "problematisch" werden. Hast du eigentlich verstanden, was der reverse proxy pound tut?

Ich bete Dir mit Absicht nicht alles klein in klein vor, weil es wichtig ist, dass Du verstehst, was Du da tust und nicht nur blind etwas abtippst.
 
Last edited by a moderator:
Danach kommst du übrigens an das zweite Problem, nämlich dass die IP deiner Besucher, sei es im Stream oder Webserver, die IP deines Servers ist.
Apache mod_rpaf löst das Problem zumindest für Webserver.

TerraX said:
Ein Wechsel des Webservers (Apache auf Nginx) will gut überlegt sein.
Click to expand...
Eigentlich meinte ich Engine-X als Reverse-Proxy, nicht Webserver.
Pound vermeide ich nach dem Snafu in deren SNI CN Implementierung welche absolut broken war (und eventuell noch ist, habe es nicht weiter verfolgt).
Aber irgendwie haben alle high-profile Reverse-Proxies solche Fehler durch mangelnde Quality assurance, bei Varnish könnte man zB das vergeigte beresp.do_stream aufführen.
 
d4f said:
Danach kommst du übrigens an das zweite Problem, nämlich dass die IP deiner Besucher, sei es im Stream oder Webserver, die IP deines Servers ist....
Click to expand...
Yepp, die X-Forwarded-Geschichte da gibt es u.U. verschiedene Ansätze, das zu lösen. Aber da wären wir schon beim Finetuning.
 
Ich hab das jetzt mal ganz anders versucht. Ich hab den Apache (und Airtime) auf Port 8080 laufen somit müsste der Port 80 frei sein.
Leider mag Airtime nicht über Port 80 mit Icecast (auch auf Port 80 gestartet) verbinden. (Port 8000 geht tatellos)
Wird irgendwo außerhalb vom Apache noch die 80 verwendet bzw. vorgehalten oder blockiert?
Code: 
netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      104        11365075    4991/icecast2
tcp        0      0 0.0.0.0:5672            0.0.0.0:*               LISTEN      106        11348434    425/beam.smp
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      0          11363188    4527/apache2
tcp        0      0 0.0.0.0:35249           0.0.0.0:*               LISTEN      106        11348332    425/beam.smp
tcp        0      0 0.0.0.0:4369            0.0.0.0:*               LISTEN      106        11348144    326/epmd
tcp        0      0 127.0.0.1:1234          0.0.0.0:*               LISTEN      107        11364357    4796/airtime-liquid
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          11348636    583/sshd
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      103        11348454    506/postgres
tcp        0      0 0.0.0.0:2812            0.0.0.0:*               LISTEN      0          11348093    288/monit
tcp6       0      0 :::22                   :::*                    LISTEN      0          11348638    583/sshd
tcp6       0      0 ::1:5432                :::*                    LISTEN      103        11348453    506/postgres

Ich hab den Port8000 Zum senden von airtime und den Port von icecast mal auf 80 gestellt und den server rebooten lassen.
Im Syslog ist nichts aber Airtime schreibt ein eigenes da steht folgendes drin:
Code: 
    2013-02-04 18:51:29,355 ERROR - [MainThread] [api_client.py : get_response_from_server()] : LINE 88 - Error Authenticating with remote server: HTTP Error 503: Service Unavailable
    2013-02-04 18:51:29,355 DEBUG - [MainThread] [api_client.py : get_response_from_server()] : LINE 92 - http://localhost:8080/api/media-monitor-setup/format/json/api_key/V703NE0LLQ9WTQHZVC4O
    2013-02-04 18:51:29,355 ERROR - [MainThread] [api_client.py : get_response_from_server()] : LINE 110 - Error connecting to server, waiting 5 seconds and trying again.
    2013-02-04 18:51:29,357 ERROR - [Thread-2] [api_client.py : get_response_from_server()] : LINE 88 - Error Authenticating with remote server: HTTP Error 503: Service Unavailable
    2013-02-04 18:51:29,357 DEBUG - [Thread-2] [api_client.py : get_response_from_server()] : LINE 92 - http://localhost:8080/api/list-all-watched-dirs/format/json/api_key/V703NE0LLQ9WTQHZVC4O
    2013-02-04 18:51:29,357 ERROR - [Thread-2] [api_client.py : get_response_from_server()] : LINE 110 - Error connecting to server, waiting 5 seconds and trying again.
    2013-02-04 18:51:34,437 INFO - [MainThread] [api_client.py : setup_media_monitor()] : LINE 384 - Connected to Airtime Server. Json Media Storage Dir: {u'watched_dirs': [], u'stor': u'/srv/airtime/stor/'}
    2013-02-04 18:51:34,537 INFO - [MainThread] [airtime.py : __init__()] : LINE 30 - Initializing RabbitMQ message consumer...
    2013-02-04 18:51:34,553 INFO - [Thread-2] [api_client.py : get_files_without_replay_gain_value()] : LINE 695 - update file system mount: []
liquidsoap (für die Übertragung zuständig) schreibt auch ein log:
Code: 
    2013/02/04 18:51:40 [stream(dot)mp3:3] Connecting mount stream.mp3 for source@88.198.160.180...
    2013/02/04 18:51:40 [stream(dot)mp3:2] Connection failed: could not write data to host: Connection refused in write()
    2013/02/04 18:51:40 [lang:3] /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could not write data to host: Connection refused in write()' --stream-id=1 --time=1360003894.42 &
    2013/02/04 18:51:40 [stream(dot)mp3:3] Will try again in 5.00 sec.
    2013/02/04 18:51:46 [stream(dot)mp3:3] Connecting mount stream.mp3 for source@88.198.160.180...
    2013/02/04 18:51:46 [stream(dot)mp3:2] Connection failed: could not write data to host: Connection refused in write()
    2013/02/04 18:51:46 [lang:3] /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could not write data to host: Connection refused in write()' --stream-id=1 --time=1360003894.42 &
    2013/02/04 18:51:46 [stream(dot)mp3:3] Will try again in 5.00 sec.
    2013/02/04 18:51:52 [stream(dot)mp3:3] Connecting mount stream.mp3 for source@88.198.160.180...
    2013/02/04 18:51:52 [stream(dot)mp3:2] Connection failed: could not write data to host: Connection refused in write()
    2013/02/04 18:51:52 [lang:3] /usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --error='could not write data to host: Connection refused in write()' --stream-id=1 --time=1360003894.42 &
    2013/02/04 18:51:52 [stream(dot)mp3:3] Will try again in 5.00 sec.
ich werde da aber auch nicht schlau draus warum die interne Kommunikation über Port 80 nicht geht.
Jemand eine Idee?
Danke Gruß Haxley
 
Port80 ist privilegiert (setzt root-Rechte voraus). Unter welchem Benutzer läuft deine Applikation?
Was genau willst du mit diesem Setup bezwecken?
 
Läuft unter root, ich will das Airtime seinen Stream zum Icecast auf Port 80 sendet, damit Icecast dann auch auf Port 80 ausliefert.

Ich brauche den Stream am Ende auf Port 80. Das ist der Sinn des Ganzen.
Gruß Haxley
 
In deinem aktuellen Setup kann aber nicht Apache auch noch auf Port 80 laufen. Du hattest doch vorhin mit reverse Proxy den richtigen Einsatz, wieso verfolgst du ihn nicht weiter?

Ich brauche den Stream am Ende auf Port 80. Das ist der Sinn des Ganzen.
Click to expand...
Das muss aber nicht durch ein Portmapping auf Port-80 und somit, je nach Software, gefährliche Root-Rechte erfolgen. Denkbar und praktikabel ist auch ein Umbiegen des Ports mittels iptables oder dem bereits angesprochenen reverse Proxy.

Übrigens scheint laut deiner Log eine 503 vom Server auf Port 80 ausgegeben worden zu sein, da läuft also was.
Bitte gib mal die Ausgabe folgenden Befehles an:
lsof -nP -i :80
 
Ich habe gedacht, warum alles umbiegen und durch zig Progs und Regeln schicken wenn es doch viel einfacher geht (also einfach intern via Port 80).
Ich bin leider nicht der Debian Profi der von jedem Ding Ahnung hat was durch irgendwelche Umleitungen tangiert wird.
Code: 
root@nebula:~# lsof -nP -i :80
root@nebula:~#
 
Haxley said:
Ich habe gedacht, warum alles umbiegen und durch zig Progs und Regeln schicken wenn es doch viel einfacher geht (also einfach intern via Port 80).
Ich bin leider nicht der Debian Profi der von jedem Ding Ahnung hat was durch irgendwelche Umleitungen tangiert wird....
Click to expand...
*seufz* Mach' Dir doch mal bitte ganz eindeutig klar, was Du willst und versuche das logisch zu durchdenken. Im Moment versuchst Du das Brett an der dünnsten Stelle zu bohren. Das wird aber nicht funktionieren.

@d4f: Warum er den ürsprünglichen Ansatz nicht mehr verfolgt? Ganz offensichtlich weil der TE damit überfordert ist und lieber auf die Schnelle völlig chaotisch herumfrickelt anstatt sich mit den aufgetretenen Problemen zu befassen und sich in die Thematik einzuarbeiten.

B2T:

Eine statische Umleitung des Traffics bzw. der Requests wird Dein Problem nicht lösen. Denn Du wolltest ja 2 Dinge: a) die Webseiten sollen ganz normal über port 80 verfügbar sein und b) auch der Icecast-Stream soll über port 80 verfügbar sein. Wenn Du also fix alle Anfragen auf Port 80 an den Icecast-Dienst weiterreichst, werden die Webseiten nicht erreichbar sein.

Ergo, wir brauchen eine intelligente Weiche, die auf Grund bestimmter Kriterien entscheiden kann, welcher Request durch welchen Serverdienst (Apache, Icecast) bearbeitet werden muss.

Wir hatten bereits festgestellt, dass ein Reverse Proxy (z.B. Pound) diese Aufgabe lösen kann. D.h. Pound nimmt alle Anfragen auf port 80 an und leitet diese je nach URL an den entsprechenden Serverdienst (Apache, Icecast) weiter. Diese müssen natürlich vorher so umkonfiguriert werden, dass sie andere Ports belegen (ungleich 80 - siehe mein config-Vorschlag). Beim Apache musst Du darauf achten, dass auch die Listen-Direktive angepasst wurde; nur den vHost anzupassen reicht nicht - yepp auch dort musst Du den neuen Port angeben, was bei Dir im ersten Versuch übrigens fehlte. (http://httpd.apache.org/docs/2.2/de/bind.html)

P.S.: Wenn Du mehrere IPs auf dem Server zur Verfügung hast, geht es auch ohne Reverse Proxy. In dem Falle setzt Du einen A-Record für IP1 auf www.meinradio.de und einen für IP2 auf stream.meinradio.de. Dann musst Du natürlich Icecast und Apache auf die entsprechende IP binden (siehe oben).
 
Last edited by a moderator:
So, ich hab das mit Pound noch mal alles eingestellt.
Apache läuft komplett auf Port 8080 Icecast auf 8000 alle die gleiche IP.

Pound:
Code: 
ListenHTTP
	Address xx.xxx.xxx.180
	Port 80
 	xHTTP 0 
	LogLevel 2
End

	Service
		 HeadRequire "Host:.*www.mysound.fm.*"
		BackEnd
			Address xx.xxx.xxx.180
			Port 8080
		End
	End

	Service
		 HeadRequire "Host:.*radio.mysound.fm.*"
		BackEnd
			Address xx.xxx.xxx.180
			Port 8000

		End
	End
Aufruf in z.B. Winamp mit xx.xxx.xxx.180:80/stream.mp3 bringt ein "Server full" verbindet aber schon mal (glaube ich).
Unter xx.xxx.xxx.180:8000/stream.mp3 geht der Stream weiterhin.

Was hab ich übersehen?

Danke Gruß Haxley
 
Dein reverse-Proxy wartet auf Host-Header (also einen Domainnamen) während du ihm laut zensiertem Link eine IP-Adresse gefüttert hast.
 
Genau genommen bindet man die Backend-Services eigentlich auf eine lokale IP (also 127.0.0.1), damit stellt man sicher, dass alle Request auch wirklich durch den Pound verteilt werden und die Dienste nicht direkt von außen angesprochen werden können. Aber das gehört dann eher zu den Feinheiten.
 
Tausend Dank für Eure Gedult, habe es hinbekommen und nun verstanden (hoffe ich mal :D)
Code: 
ListenHTTP
	Address xx.xxx.xxx.180
	Port 80
 	xHTTP 0 
	LogLevel 2
End

	Service
		 HeadRequire "Host:.*airtime.myradio.fm.*"
		BackEnd
			Address xxx.xxx.xxx.180
			Port 8080
		End
	End

	Service
		 HeadRequire "Host:.*sound.myradio.fm.*" 
		BackEnd
			Address 127.0.0.1
			Port 8000

		End
	End
Der Stream geht über eine Subdomain an Port 80 und Airtime ist auch via Subdomain erreichbar. Mehr wollte ich erstmal nicht.


Wirklich noch mal ganz vielen DANK!
 
You must log in or register to reply here.
Back
Top