Für September hatte ich mir vorgenommen einige Ubuntu Server von 14.04 LTS auf 16.04 LTS zu bringen. Die 14er LTS erhält zwar noch bis ca. April 2019 Updates, aber die 16er gibt es jetzt ja auch schon etwas über ein Jahr und bringt zudem offiziell PHP7 mit (ja ich weiß man kann es auch in der 14er installieren). Wie üblich empfiehlt sich ein Backup vom System und allen benötigten Daten auf dem Server zu haben. Neben den Backups habe ich das Glück das meine Ubuntu Server alle virtualisiert auf über ESX Server laufen und sich somit Snapshots anfertigen lassen.
Vor jedem Release upgrade sollte man das momentane System so aktuell wie möglich halten. Also vorher nochmal:
apt-get update
und
apt-get upgradedurchführen. Außerdem empfiehlt sich auch ein
apt-get autoremove
um nicht mehr benötigte Pakete zu entfernen. Das lässt sich übrigens auch automatisieren.
Außerdem sollte man mit df -h auch mal schnell checken ob genügend Platz auf den Partitionen zur Verfügung steht. Auf einem Server war die /boot Partition so ziemlich voll und enthielt noch einige alte Kernel Versionen die ich dann vorher entfernt habe. Bevor man das macht sollte man sich aber mit uname -r vergewissern welcher Kernel aktuell verwendet wird und diesen natürlich auf keinen Fall entfernen.
Dann kann es mit
do-release upgrade
losgehen. Ubuntu leitet euch dann etwas durch den Vorgang und fragt bei neueren Configs nach ob diese eingebunden werden sollen oder lieber die alten verwendet werden sollen. Ich bleibe zu 99% bei den alten, sollten einige Dienste mit den alten Configs Probleme machen, lassen sich diese später noch verstehen und beheben, was ich deutlich besser finde als angepasste Configs zu verlieren.
Wenn das Upgrade durchgelaufen ist hatte ich meistens immer Probleme mit dem Netzwerk, was wohl auch an der Virtualisierung liegt. Auf jeden Fall wurde aus eth0 meistens irgendwas anderes. Mit ip link lässt sich aber schnell der neue Name der Netzwerkkarte rausfinden. Danach dann unter /etc/network/interfaces eth0 durch den neuen Namen ersetzen und das Netzwerk oder den Server neustarten. Danach sollte der Server wieder laufen und mann kann seine Dienste checken und z.B. PHP 7 installieren.
Hat man für eine Webseite SSL (https) eingerichtet kann man den Benutzer automatisch dazu zwingen die Seite nur noch verschlüsselt aufzurufen. Verwendet man als Webserver Apache geht dies wie folgt: Im Netz finden sich viele Beispiele im Zusammenspiel mit mod_rewrite, allerdings empfehlen die Apache Entwickler diese Technik für diesen Fall nicht unbedingt (hier nachzulesen: http://httpd.apache.org/docs/2.4/rewrite/avoid.html). Stattdessen reicht in der Seitenkonfiguration ein einfaches:
<VirtualHost *:80>
...
Redirect / https://www.domain.de
...
</VirtualHost>Wer es trotzdem mit mod_rewrite machen will oder muss, kann dazu folgende Zeilen verwenden, ebenfalls in der Config oder über eine .htaccess Datei:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://www.doamin.de%{REQUEST_URI} [R=301,L]Soweit so gut, wer jetzt noch eine ordentliche URLmag und auch immer das www in der Adresszeile haben will, egal ob der Benutzer es eingibt oder nicht, der muss etwas tricksen. Zumindest habe ich keinen einfacheren Weg gefunden. Und zwar muss man seine SSL Config klonen, bzw. zwei Virtual Hosts für SSL einrichten. Der erste ist für die URL ohne www
<VirtualHost *:443>
ServerName domain.de
....
Redirect / https://www.domain.de
</VirtualHost>Und der zweite dann für eure URL mit www.
<VirtualHost *:443>
ServerName www.domain.de
....
</VirtualHost>Was passiert? Alle https Anfragen ohne www werden dann umgeleitet auf mit www. Wichtig ist das beide Virtual Host Konfigurationen ansonsten identisch sind, also mit Directory und SSLEngine On etc.
Über mod_rewrite habe ich keinen Weg gefunden https ohne www auf https mit www umzuleiten. Hat bei mir alles mit der Kombination aus SSL erzwingen nicht funktioniert.
Wer ein Internetradio besitzt kann durchaus auf die Idee kommen dort auch seine eigene Musik zu hören. Das geht bei den meisten Geräten per USB Stick, Medienserver (DLNA), Bluetooth oder auch per AUX-In. Das genügte mir jedoch nicht, denn ich halte es gerne einfach, Radio an, Musik ab. Kein koppeln und kein Zusatzgerät in Reichweite notwendig. In dem Fall lohnt sich eine eigene Radiostation, die lässt sich dank Icecast schnell und einfach einrichten und läuft auch auf schmaler Hardware gut, z.B. auf einem alten Server oder günstigem vServer, einem Rasperry Pi etc. Bei Debian und/oder Ubuntu als Betriebssystem ist Icecast teil der offiziellen Quellen, also reicht ein:
apt-get install icecast2
zur Installation.
Falls man nicht automatisch dazu aufgefordert wird muss man danach nur noch die Konfiguration anpassen:
(sudo) vi /etc/icecast2/icecast.xml
Die meisten Settings kann man für den privaten Gebrauch lassen wie sie sind.
<clients>5</clients>
<sources>1</sources>Habe ich auf 5 und 1 gesetzt. Wer später nur über ein Gerät hören will kann hier theoretisch auch beides auf 1 setzen. Das hängt davon ab von wie vielen Geräten man später gleichzeitig den Sender hören will. Wichtig ist noch der Bereich zwischen:
<authentication>
<!-- Sources log in with username 'source' -->
<source-password>******</source-password>
<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>******</admin-password>
</authentication>Dort sollte man auf jeden Fall Passwörter vergeben, zum einen für das Webinterface des Admins und zum anderen um später Musik über den Sender verbreiten zu können. Ohne Passwort könnte theoretisch jeder Musik über euren Sender schicken. In der Configdatei kann man nach Wunsch auch den Port des Senders ändern (Default 8080) und auch das Directory Listing. Ich empfehle das Listing deaktiviert zu lassen, sonst wird euer Sender auch öffentlich gefunden (sofern euer Server im Internet erreichbar ist) und dann sollte man sich vorher auf jeden Fall mit Musikrechten beschäftigen.
Das war es dann schon und man kann den Server starten:
/etc/init.d/icecast2 start
oder auch
service icecast2 start
Ob alles klappt kann man einfach über den Browser probieren. http://ip-eures-servers:8000 aufrufen und ihr erhaltet die Statusseite des Icecast Servers. Jetzt läuft also der Radioserver, aber ohne Musik. Also muss man den Server füttern. Dazu gibt es viele Möglichkeiten, aber eine einfache über die Kommandozeile ist Ezstream. Vorteil: Ezstream kann auch mit mp3 Dateien umgehen. Also erfolgt ein:
apt-get install ezstream
auf dem Server/PC auf dem die Musik liegt die man senden will. Hier muss man dann erst eine XML Konfiguration erstellen, es gibt verschiedene Vorlagen unter:
/usr/share/doc/ezstream/examples/
Eine fertige Konfiguration für mp3 Dateien könnte wie folgt aussehen:
<ezstream>
<url>http://eure-server-ip:8000/stream</url>
<sourcepassword>Icecast Source Passwort (s.o.)</sourcepassword>
<format>MP3</format>
<!-- Pfad zur Musikplaylist -->
<filename>/pfad/zu/eurer/mp3/playlist.m3u</filename>
<!-- Playlist wird endlos wiederholt mit Zufallswiedergabe -->
<stream_once>0</stream_once>
<shuffle>1</shuffle>
<!-- ein paar Zusatzinfos, wird später am Radiodisplay zu sehen sein-->
<svrinfoname>Radio Brice</svrinfoname>
<svrinfogenre>Mix</svrinfogenre>
<svrinfodescription>Best music on the planet</svrinfodescription>
<svrinfobitrate>128</svrinfobitrate>
<svrinfochannels>2</svrinfochannels>
<svrinfosamplerate>44100</svrinfosamplerate>
<!--
Prohibit the server to advertise the stream on a public YP directory:
-->
<svrinfopublic>0</svrinfopublic>
</ezstream>Die Konfiguration kann man radio_config.xml nennen oder wie auch immer und z.B. im Homeverzeichnis ablegen.
UPDATE: Seit Anfang 2020 gibt es ezstream in der Version ezstream-1.0.0 und momentan auch 1.0.1 Aktuelle Linux Distributionen liefern über APT mittlerweile ebenfalls diese Versionen aus. Nun könnte man theoretisch auch Videos streamen und es wird auch TLS angeboten (sehr sinnvoll z.B. wenn der Icecast Server nicht im gleichen Netz steht). Ab der Version 1.0 hat sich auch das Konfigurationsschema geändert und obiges Beispiel funktionierte bei mir nicht mehr. Es müssen jetzt 3 Blöcke bestehend aus Servers, Streams und Intakes definiert werden. Beispiel für eine funktionierende Konfiguration mit ezstream-1.0.1 und Icecast2 für einen mp3 Stream:
<ezstream>
<servers>
<server>
<hostname>eure Server IP</hostname>
<password>Icecast Source Passwort (s.o.)</password>
<port>8080</port> <!-- Optional, default ist 8000 -->
</server>
</servers>
<streams>
<stream>
<public>No</public>
<mountpoint>/stream</mountpoint>
<format>MP3</format>
<stream_name>Name eures Radios</stream_name>
<stream_quality>1.5</stream_quality>
<stream_bitrate>16</stream_bitrate>
<stream_samplerate>44100</stream_samplerate>
<stream_channels>2</stream_channels>
</stream>
</streams>
<intakes>
<intake>
<type>playlist</type>
<filename>/pfad/zu/eurer/mp3/playlist.m3u</filename>
<!-- Setting to shuffle playlists -->
<shuffle>Yes</shuffle>
</intake>
</intakes>
</ezstream>Jetzt muss man nur noch eine Playlist erstellen und dort ablegen wo man es in der Config angegeben hat. Dabei hilft z.B. der folgende Befehl:
find /pfad/zu/eurern/mp3s/ -name "*.mp3" > /pfad/zu/eurer/mp3/playlist.m3u
So werden alle mp3 Dateien unter dem Pfad in die Playlist geschrieben.
Jetzt einfach ezstream starten und fertig.
ezstream -c name_und_pfad_der_ezstream_config.xml
Alternativ lässt sich der Prozess auch mit nohup in den Hintergrund schicken, dann endet der Stream nicht wenn man die Konsole verlässt:
nohup ezstream -c name_und_pfad_der_ezstream_config.xml &
Am Internetradio oder am Player nach Wahl http://eure-server-ip:8000/stream öffnen und es sollte etwas zu hören sein. Über die Icecast Webpage (s.o.) lässt sich der Status des Streams verfolgen.