Suche

lichtschattenblog

Kategorie

Batch

unbeaufsichtigte Installation von Kodi unter Windows

Vorab: Bei Verwendung der hier genannten Skripte und eventuell resultierenden Schäden übernehme ich keine Haftung. Jegliche Verwendung erfolgt auf eigene Gefahr.

 

Zur unbeaufsichtigten Installation und Deinstallation von Kodi gibt es ein paar Möglichkeiten dies auszuführen.

Wichtig ist vorab die Logik zur Konfiguration von Kodi zu verstehen. Die zusammenfassend sind:

  • eine Installation von Kodi im Silent Mode kann mit dem Argument /S durchgeführt werden
  • Anpassungen von Kodi werden unter Windows unterhalb %appdata% des jeweiligen Benutzers gespeichert
  • für eine angepasste Installation und Konfiguration müssen alle wichtigen Dateien zu den vorgenommen Anpassungen erkannt und gespeichert werden. Dies kann ggf. nur durch ausprobieren erfolgen
  • teilweise können Konfigurationsdateien aus älteren Kodi-Versionen problemlos übernommen werden. Ggf. erfolgt eine automatische Aktualisierung einiger Dateien, wie db-Dateien

In meinem Fall wurde ein Kodi in Version 17.6 verwendet. Abweichend zur Standardinstallation liegen Anpassungen zur Verwendung von tvheadend (pvr.hts), deutscher Oberfläche, dem Skin, reduzierten Menüs (keine Bilder, keine Musikdatenbank, keine Videodatenbank), reduzierten Benutzerrechten (aktiviertem Master-Password) und Verwendung einer Hama-Fernbedienung vor. In diesem Fall sind die Anpassungen in den folgenden Dateien gespeichert:

Wie kann nun die unbeaufsichtigte Installation erfolgen?

Zunächst kopieren wir das Verzeichnis kodi aus %appdata% bzw. c:\users\<dein benutzername>\AppData\Roaming in eine geeignete Freigabe (bei Verwendung meiner Skripte zusätzlich in den Unterordner appdata) auf einem Server und löschen alle nicht relevanten Dateien und Ordner in der Kopie. Wer Anpassungen in weiteren Addons durchgeführt hat, muss speziell die Dateien unterhalb …\kodi\userdata\addon_data berücksichtigen.

Anschließend kann die Verteilung automatisiert über eine Gruppenrichtlinie (gpo) oder wie in meinem Fall über einen Remoteinstallationsserver (Remote Installer von Firma emco software: https://emcosoftware.com/) erfolgen. Vorteil ist die Installation und Aktualisierung von Programmen zum laufenden Betrieb.

Anbei die von mir selbst erstellten Skripte. Die Verwendung mit diesen Skripten bei Installation von Kodi 17.6 war bisher unter Windows 10 problemlos. Unter Windows 7 gab es wenige Rechner wo die Installation nicht möglich war, da ein notwendiges Windows-Update nicht installiert werden konnte (bei manueller Installation erscheint eine Fehlermeldung die mit <Enter> bestätigt werden muss). In diesem Fall und Einsatz von Gruppenrichtlinien würde die Installation nicht erfolgreich sein und erst nach 15 Minuten zum Rechnerstart die Installation abgebrochen werden. Daher empfehle ich unter Windows 7 Kodi 16.

Anbei die drei Skripte, welche in der Freigabe gespeichert werden. In diesem Verzeichnis gibt es die Installationsdatei kodi-17.6-Krypton-x86.exe und das Unterverzeichnis appdata mit den entsprechenden Dateien vom kodi (<Verzeichnis als Freigabe>\appdata\kodi).

Hinweis: In meinen Skripten ist das Verzeichnis kodi unterhalb %appdata% weiterhin vorhanden!

 

install_kodi.bat

@echo off

set "install_file=%~dp0kodi-17.6-Krypton-x86.exe"
set "refresh_appdata_script=%~dp0kodi_refresh_appdata.bat"
set "win10_kodi_lnk=C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Kodi\Kodi.lnk"


:KILL_KODI_PROCESS
taskkill /F /IM kodi.exe /T > nul


:INSTALL_KODI
"%install_file%" /S


:REFRESH_APPDATA_KODI
call "%refresh_appdata_script%"


:CREATE_KODI_LNK
REM needs admin rights
if EXIST "%win10_kodi_lnk%" (

xcopy "%win10_kodi_lnk%" "%allusersprofile%\Desktop" /R /Y > nul

)

 

kodi_refresh_appdata.bat

@echo off

set "appdata_source=\\<servername>\kodi$\appdata"

if NOT "%ProgramFiles(x86)%" == "" (
if EXIST "%ProgramFiles(x86)%\kodi\kodi.exe" GOTO REFRESH_APPDATA_KODI
) else (
if EXIST "%ProgramFiles%\kodi\kodi.exe" GOTO REFRESH_APPDATA_KODI
)

GOTO END


:REFRESH_APPDATA_KODI
if NOT "%appdata_source%" == "" (
for /F "delims=*" %%a in ('dir /B c:\Users ^| find /V /I "TEMP" ^| find /V /I "Public" ^| find /V /I "Default.migrated"') do (
if EXIST "c:\users\%%a\AppData\Roaming\" (
echo try: xcopy "%appdata_source%" "c:\users\%%a\AppData\Roaming\" /E /C /I /R /Y
xcopy "%appdata_source%" "c:\users\%%a\AppData\Roaming\" /E /C /I /R /Y
)
)
)

:END

remove_kodi.bat

@echo off

set "win10_kodi_lnk=C:\Users\Public\Desktop\Kodi.lnk"


:KILL_KODI_PROCESS
taskkill /F /IM kodi.exe /T > nul


:START_UNINSTALL_KODI
if NOT "%ProgramFiles(x86)%" == "" (
if EXIST "%ProgramFiles(x86)%\kodi\uninstall.exe" ( "%ProgramFiles(x86)%\kodi\uninstall.exe" /S )
) else (
if EXIST "%ProgramFiles%\kodi\uninstall.exe" ( "%ProgramFiles%\kodi\kodi.exe" /S )
)

:CLEAN_APPDATA_KODI

for /F "delims=*" %%a in ('dir /B c:\Users ^| find /V /I "TEMP" ^| find /V /I "Public" ^| find /V /I "Default.migrated"') do (
if EXIST "c:\users\%%a\AppData\Roaming\Kodi" (
echo try: rmdir /S /Q "c:\users\%%a\AppData\Roaming\Kodi\"
rmdir /S /Q "c:\users\%%a\AppData\Roaming\Kodi\"
)
)

:REMOVE_DESKTOP_LINK
if EXIST "%win10_kodi_lnk%" (
del "%win10_kodi_lnk%"
)

 

Anbei ein paar Erläuterungen zum Skript install_kodi.bat:

  • %~dp0 bedeutet das Verzeichnis indem sich die install_kodi.bat befindet
  • %~dp0kodi-17.6-Krypton-x86.exe ist somit bei Ausführung \\<servername>\<freigabe>\kodi-17.6-Krypton-x86.exe
  • zu Beginn wird ein ggf. bestehender Kodi-Prozess beendet
  • die Installation von Kodi mit Option /S wird durchgeführt (großes S !!!)
  • kodi_refresh_appdata.bat wird gestartet
  • Verknüpfung zum Aufruf von Kodi wird auf den Desktop für alle Benutzer kopiert
  • mit diesem Skript kann auch eine Aktualisierung oder Neuinstallation von Kodi erfolgen

Ein paar Erläuterungen zum kodi_refresh_appdata.bat:

  • zu Beginn wird das Verzeichnis mit der AppData-Kopie von kodi definiert
  • Hinweis: sofern mehrere Verzeichnisse mit abweichender AppData-Kopie definiert werden müssen (Beispiel mehrere TVHeadend-Server), kann dies ggf. durch Abgleich mit dem Standardgateway erfolgen:
    ipconfig | find /I „192.168.x.x“ if %ERRORLEVEL% == 0 ( set „appdata_source=\\<servername>\kodi$\appdata_standort1“ )
  • es wird geprüft ob Kodi installiert ist und wenn ja werden die Kodi-Konfigurationsdateien für alle Benutzer auf dem jeweiligen System (außer Public, Temp und Default.Migrated) aktualisiert
  • dieses Skript kann separat bei einer bereits erfolgten Installation zur Konfigurationsaktualisierung verwendet werden
  • die Verwendung erfordert vollen administrativen Zugriff auf die Verzeichnisse der verschiedenen Benutzer

Ein paar WICHTIGE Erläuterungen zu remove_kodi.bat:

  • zu Beginn wird ein ggf. bestehender Kodi-Prozess beendet
  • die Deinstallation von kodi über uninstall.exe mit Option /S wird durchgeführt (großes S !!!)
  • für alle Benutzerprofile auf dem PC werden die Konfigurationsdateien vom Kodi gelöscht
    Wer dies nicht möchte muss die Zeile:
    rmdir /S /Q „c:\users\%%a\AppData\Roaming\Kodi\“
    löschen oder REM zu Beginn der Zeile:
    rmdir /S /Q „c:\users\%%a\AppData\Roaming\Kodi\“
    schreiben.
    also: REM rmdir /S /Q „c:\users\%%a\AppData\Roaming\Kodi\“
    Bei falscher Anwendung und Anpassung dieser Zeile besteht die Möglichkeit von Datenverlust. Ggf. diese Zeile löschen!!!
  • es wird die Desktop-Verknüpfung von Kodi gelöscht
Advertisements

PRTG – Skript zur Abfrage am Remote MS Windows Server – XML-Datensatz

Zur Überwachung des Lastenausgleichs einer Citrix XenApp-Server-Umgebung war es notwendig die Befehlsausgabe von qfarm /load via XML im PRTG einzulesen. Es besteht hierbei natürlich die Möglichkeit dies für andere Systeme und Befehle zu verwenden.

Eine typische Ausgabe von qfarm /load ist:

prtg_gfarm_load_example

Bei meinen Tests habe ich zwei Varianten erfolgreich testen können. Ich persönlich bevorzuge Variante 1 mit PowerShell. Variante 2 via batch-Skripte und Freigabe hat den Nachtteil, das ggf. das Skript per Hand gestartet und zusätzlich die Ausführung überwacht werden muss. Kann aber im Bedarfsfall ein guter Ersatz sein.

Variante 1 – via Powershell-Skript:

Bei dieser Variante mittels Powershell muss zunächst sichergestellt werden, dass der Remote-Server sogenannte Invoke-Commands erfolgreich akzeptiert. Dies machen wir auf unserem PRTG-Server mittels dem Powershell-Befehl:

  • test-wsman <Remote-Server>

Wenn die Konfiguration noch nicht korrekt ist, erhalten wir folgende Meldung:

prtg_powershell_test

In diesem Fall führen wir die folgenden Befehle aus:

  • Enable-PSRemoting -Force
  • Set-Item wsman:\localhost\client\trustedhosts *
  • Restart-Service WinRM

Wer nicht allen Systemen die Remote-Ausführung von PowerShell-Befehlen gestatten will muss das * im zweiten Befehl mit einer Liste der gewünschten Systeme austauschen.

  • Set-Item wsman:\localhost\client\trustedhosts „server01, server02“

Hinweis: Bei jeder Änderung muss der dritte Befehl erneut ausgeführt werden.

Wenn die Konfiguration korrekt ist erhalten wir zur Ausführung des PowerShell-Befehls:

  • test-wsman <Remote-Server>

prtg_powershell_test_success

Hinweis: Zum erweiterten Test, mit der Möglichkeit PowerShell-Befehle direkt auf dem Remote-Server ausführen zu können und dass die bestehenden Rechte ausreichend sind, stehen folgende PowerShell-Befehle zur Verfügung:

  • Enter-PSSession -ComputerName
  • Enter-PSSession -ComputerName <Remote-Server> -Credential <Remote-Username>

Jetzt erstellen wir auf unserem Remote-Server ein geeignetes Verzeichnis und hinterlegen dort eine entsprechende Skript-Datei. In meinem Fall C:\PRTG und:

  • prtg_get_qfarm_load.ps1

In dieser Datei hinterlegen wir folgenden Code:

Set-ExecutionPolicy Unrestricted

[string]$cmd = 'qfarm'
[string]$par = '/load'

[array]$cmdoutput = & $cmd $par

$cmdoutput = $cmdoutput[3..($cmdoutput.length)]

Write-Host '<?xml version="1.0" encoding="Windows-1252" ?>'
Write-Host '<prtg>'

foreach ($line in $cmdoutput) {

 $line = $line -replace '\s+', ' '

 $lineparts = $line.Split(' ')

 Write-Host ' <result>'
 Write-Host -Separator '' '  <channel>'$lineparts[0]' - LOAD</channel>'
 Write-Host -Separator '' '  <value>'$lineparts[1]'</value>'
 Write-Host '  <unit>Load</unit>'
 Write-Host '  <float>0</float>'
 Write-Host '  <LimitMaxError>10000</LimitMaxError>'
 Write-Host '  <LimitErrorMsg>Server'$lineparts[0]'ist maximal ausgelastet. Prozessorlast bzw. RAM-Nutzung zu hoch. Bitte korrigieren!</LimitErrorMsg>'
 Write-Host '  <showChart>1</showChart>'
 Write-Host '  <showTable>1</showTable>'
 Write-Host '  <LimitMode>1</LimitMode>'

 Write-Host ' </result>'

}

Write-Host '</prtg>'

Führen wir nun die Datei in der powershell aus bekommen wir eine Ausgabe ähnlich:

prtg_qfarm_load_ps1_test

Jetzt müssen wir nur noch auf unserem PRTG-Server dafür sorgen, dass dieses Skript remote aufgerufen wird. Hierzu erstellen wir auf unserem PRTG-Server im Verzeichnis:

C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML

eine entsprechende PowerShell-Datei. In meinem Fall:

  • prtg_get_qfarm_load_remote.ps1

In dieser Datei fügen wir folgenden kurzen Code ein:

Invoke-Command -ComputerName $args[0] -ScriptBlock { & C:\PRTG\prtg_get_qfarm_load.ps1 }

Hinweis: Ggf. den Namen der PowerShell-Datei auf dem Remote-Server anpassen!

Zum Test wechseln wir in die Powershell und rufen das Skript mit dem Computernamen des Remoteservers als alleiniges Argument auf:

& 'C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML\prtg_get_qfarm_load_remote.ps1' <Remote-Server>

und erhalten als Beispiel:

prtg_qfarm_load_remote_ps1_test

Hinweis: Zur Ausführung des Befehls auf meinem PRTG-Server steht oben rechts PS. Wenn durch Tests mit Eurem Remote-Server dort dessen Name zu sehen ist, arbeitet ihr in der PowerShell auf dem falschen System!

Im PRTG selbst fügen wir bei unserem bestehenden Server einen neuen Sensor vom Typ:

  • Programm/Skript (erweitert)

hinzu. Im zweiten Schritt ist zwingend darauf zu achten, dass der Sicherheitskontext auf „Die Anmeldedaten für Windows des übergeordneten Geräts verwenden“ gesetzt ist und unser Skript ausgewählt ist. Bitte beachten dass ggf. die Anmeldeinformationen vom Server gesetzt werden müssen.

prtg_qfarm_load_add_sensor.jpg

Nach zweimaliger Ausführung des Skripts durch den Server sehen wir nun:

prtg_qfarm_load_final_sensor_v2

 

Variante 2 – via batch-Skripte und Freigabe

Eine zweite Variante, die ich mir im Vorfeld überlegt und getestet habe, ist die lokale Ausführung eines batch-Skriptes, in einer Schleife, auf dem Remote-Server.

Hierzu habe ich auf dem Remote-Server ein Verzeichnis PRTG angelegt und als PRTG$-Freigabe für den PRTG-Server verfügbar gemacht.

In das Verzeichnis habe ich eine Datei: prtg_get_qfarm_load.bat erstellt.

@echo off

SET "TEMPOUTPUTFILE=C:\PRTG\prtg_get_qfarm_load.tmp"
SET "OUTPUTFILE=C:\PRTG\prtg_get_qfarm_load.xml"

:LOOP

if NOT "%OUTPUTFILE%" == "" (

 (

 echo ^<?xml version="1.0" encoding="Windows-1252" ?^>
 echo ^<prtg^>

 for /f "skip=2 tokens=1,2 delims= " %%a in ('qfarm /load ^| findstr /v /r /i "^--"') do (

  echo ^<result^>
  echo  ^<channel^>%%a - LOAD^</channel^>
  echo  ^<value^>%%b^</value^>
  echo  ^<unit^>Load^</unit^>
  echo  ^<float^>0^</float^>
  echo  ^<LimitMaxError^>10000^</LimitMaxError^>
  echo  ^<LimitErrorMsg^>Server %%a ist maximal ausgelastet. Prozessorlast bzw. RAM-Nutzung zu hoch. Bitte korrigieren! ^</LimitErrorMsg^>
  echo  ^<showChart^>1^</showChart^>
  echo  ^<showTable^>1^</showTable^>
  echo  ^<LimitMode^>1^</LimitMode^>
  echo ^</result^>

  )

 echo ^</prtg^>
 ) > "%TEMPOUTPUTFILE%"

move %TEMPOUTPUTFILE% %OUTPUTFILE%

TIMEOUT /T 10 /NOBREAK > nul
GOTO LOOP

)

 

Zur Ausführung der Skript-Datei wird eine Temp-Datei als XML erzeugt, da die Ausführungszeit von qfarm /load ggf. zu lang ist und das Ergebnis vom PRTG-Server nicht vollständig gelesen wird. In diesem Fall hätten wir einen Fehler im PRTG. Nach Abschluss der Generierung der Temp-Datei wird diese in die Zieldatei umbenannt und die alte XML-Datei überschrieben. Das Skript führt die Schleife alle 10 Sekunden aus.

Damit diese Batch-Datei auf dem Server nicht sichtbar ist, habe ich diese mit dem Tool Bat-To-Exe-Converter, Portable Variante, mit folgendem Befehl in eine exe-Datei umgewandelt:

Bat_To_Exe_Converter.exe -bat c:\prtg\prtg_get_qfarm_load.bat -save c:\prtg\prtg_get_qfarm_load.exe -invisible

Durch einmalige manuelle Ausführung der prtg_get_qfarm_load.exe-Datei wird nun alle 10 Sekunden die gewünschte XML-Datei generiert.

Hinweis: Um diesen Vorgang beenden zu können, muss der laufende Prozess prtg_get_qfarm_load.exe über den TaskManager oder taskkill-Befehl beendet werden (Bsp.: taskkill /F /IM prtg_get_qfarm_load.exe /T).

Hinweis: Meine ursprüngliche Idee war die Erstellung eines Dienstes mit dem Befehl sc create. Leider war dies nicht erfolgreich. Wer hierzu erfolgreich eine exe-Datei als Dienst aktivieren konnte, mir bitte einen Kommentar senden. Gerne hinterlege ich hier die funktionierende Variante.

Zum Abruf der Daten in der XML-Datei ist erforderlich dies über ein Skript ans PRTG zu übergeben. Nach Auskunft vom PRTG-Support besteht nicht die Möglichkeit XML-Dateien direkt einzulesen.

Auf dem PRTG-Server, im Verzeichnis C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML habe ich eine Datei read_prtg_get_qfarm_load.bat erstellt, deren Aufgabe lediglich die Ausgabe des Dateiinhaltes ist.

@echo off
type \\<remote-server>\prtg$\prtg_get_qfarm_load.xml

Im PRTG selbst fügen wir bei unserem bestehenden Server einen neuen Sensor vom Typ:

  • Programm/Skript (erweitert)

hinzu und wählen dass von uns hinterlegte Skript aus:

prtg_qfarm_load_batch_add_sensor

Auch hier sehen wir nach zweimaliger Abfrage des Sensors:

prtg_qfarm_load_batch_final_sensor

 

Quellen:

Citrix GoToMeeting-Probleme in einer gemischten Struktur mit Verwendung eines Proxy

Mittels Citrix GoToMeeting ist es möglich Meetings mit Bildübertragung durchzuführen. Leider ist durch ein automatisches Update, der Software unter MS Windows, die korrekte Nutzung über einen Proxy derzeit nicht möglich.

In Umgebungen, wo für einzelne PCs die direkte Nutzung ohne Proxy aktiviert wurde, ist es möglich ein erneutes Setzen der Proxy-Einstellungen via GPO zu verhindern. Jedoch kann es passieren dass die Proxy-Einstellungen über Benutzerprofile synchronisiert werden.

Zusätzlich übernimmt Mozilla Firefox sehr gerne die Proxy-Einstellungen vom Internet Explorer und auch Citrix GoToMeeting prüft zum Start auf vorhandenen Proxy-Einstellungen im Internet Explorer und Mozilla Firefox.

Im Ergebnis ist es sehr schwierig GoToMeeting mitzuteilen dass kein Proxy notwendig ist. Zur Lösung im Problemfall müssen per Hand die Prozesse von GoToMeeting (beginnend g2m*) beendet werden. Anschließend müssen die Proxy-Einstellungen in den Web Browsern deaktiviert werden. Zum Ende müssen noch die Registrierungswerte unterhalb HKEY_CURRENT_USER\SOFTWARE\Citrix gelöscht werden. Anschließend kann GoToMeeting gestartet werden.

Als Alternative habe ich hierzu folgendes Skript geschrieben, welches erfolgreich unter MS Windows 7 und MS Windows 10 getestet wurde. Dies kann entweder per Hand gestartet oder zur Benutzeranmeldung an bestimmten Systemen ausgeführt werden.

Hinweis: Zur Ausführung werden Mozilla Firefox und Internet Explorer automatisch beendet!

 

@echo off
SETLOCAL ENABLEEXTENSIONS
set killtasks=g2mcomm.exe g2mlauncher.exe g2mstart.exe iexplore.exe firefox.exe


:KILLTASKS

(for %%a in (%killtasks%) do (
 echo try: taskkill /IM %%a /F
 taskkill /IM %%a /F
 )
)

(for %%a in (%killtasks%) do (
 echo try: taskkill /IM %%a /F
 taskkill /IM %%a /F
 )
)


:INTERNETEXPLORER

REG ADD "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v "ProxyEnable" /t REG_DWORD /d "0" /f
REG DELETE "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v "ProxyOverride" /f
REG DELETE "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v "AutoConfigURL" /f
REG DELETE "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v "ProxyServer" /f


:FIREFOX

cd /D "%APPDATA%\Mozilla\Firefox\Profiles"
cd *.default*

set cd=%CD%
set file=%CD%\prefs.js

For /f "tokens=3 delims=." %%a in ('date /t') do (set sDateTime=%%a)
For /f "tokens=1-2 delims=." %%a in ('date /t') do (set sDateTime=%sDateTime:~0,4%_%%b_%%a)
For /f "tokens=1-2 delims=:" %%a in ('time /t') do (set sDateTime=%sDateTime%_%%a_%%b)

set backup=%CD%\prefs.js_%sDateTime%

if EXIST %file% ( copy %file% %backup% /Y )
if EXIST %backup% ( type %backup% | findstr /v "network.proxy" > %file% )

echo type %file% | findstr "network.proxy"
type %file% | findstr "network.proxy"
if %ERRORLEVEL% neq 0 ( echo user_pref^(^"network.proxy.type^", 0^); >> %file% )


:GOTOMEETING

Reg Delete "HKEY_CURRENT_USER\SOFTWARE\Citrix" /f


:END

 

Hinweis:

Die Prozesse werden bewusst doppelt beendet, da sie sich gegenseitig überwachen und teilweise erneut gestartet werden. Für mögliche Probleme beim Arbeiten mit der prefs.js vom Firefox, wird hier auf Basis von Datum und Uhrzeit eine Kopie verwendet, die nicht gelöscht wird. Sofern eine Löschung erfolgen soll, kann dies am Ende des Skript mittels:

del %backup%

erfolgen.

Wer lediglich eine Lösung zur Deaktivierung der Proxy-Einstellungen im Internet Explorer und Mozilla Firefox sucht, muss einfach nur die ersten zwei Zeilen plus die Zeilen nach :FIREFOX, bzw. :INTERNETEXPLORER verwenden.

 

 

 

Erstelle eine kostenlose Website oder Blog – auf WordPress.com.

Nach oben ↑