Solltest du dein Passwort für den User root vergessen haben, kannst du das mit https://dev.mysql.com/doc/refman/5.7/en/resetting-permissions.html zurücksetzen. Sollte das nicht funktionieren - kannst du die folgende Alternative verwenden:

1. Öffne die Datei mysql.cnf und füge unter [mysqld]

   skip-grant-tables
   

   ein

2. Starte danach mysql

3. Logge dich mit

   mysql -u root mysql
   

   ein

4. Dann

   FLUSH PRIVILEGES;
   

   und den Passwort Befehl aus resetting-permission eingeben (je nachdem welche Version von mysql man hat)

   ALTER USER ‘root‘@’localhost’ IDENTIFIED BY ‘MyNewPass’;
   or
   SET PASSWORD FOR ‘root‘@’localhost’ = PASSWORD(‘MyNewPass’);

   und danach

   update user set plugin="mysql_native_password"; # THIS LINE
   FLUSH PRIVILEGES;
   

   sollte das nicht gehen - kann man auch noch

   update user set authentication_string=PASSWORD("") where User='root';
   

   versuchen.

5. Danach skip-grant-tables wieder aus der mysql.cnf entfernen und mysql neustarten.

Mit Firebase Cloud Messaging, kurz FCM, kann man Notifications auf IOS und Android versenden. Im folgenden Beitrag geht es um das Versenden der Nachrichten im Backend mit PHP. Um mit PHP Nachrichten an FCM zu schicken kann die Library

“paragraph1/php-fcm”: “^0.7.0”

verwendet werden. Damit man Daten aus der Firebase Database verwenden kann, verwendet man zusätzlich noch die Library:

“kreait/firebase-php”: “^2.0”,

Damit ergibt sich das folgende composer File:

{
“require”: {
“kreait/firebase-php”: “^2.0”,
“paragraph1/php-fcm”: “^0.7.0”
}
}

Um mit Firebase zu arbeiten erstellen wir eine backend.php Datei:

<?php
require ‘vendor/autoload.php’;

use paragraph1\phpFCM\Client;
use paragraph1\phpFCM\Message;
use paragraph1\phpFCM\Recipient\Device;
use paragraph1\phpFCM\Recipient\Topic;
use paragraph1\phpFCM\Notification;

$firebase = Firebase::fromServiceAccount(__DIR__.’/secret/firebaseappname-firebase-adminsdk-uuid.json’);
$apiKey = ‘ffcmApiKey-findetmanunterProjekteinstellungenCloudMessaging’;
$client = new Client();
$client->setApiKey($apiKey);
$client->injectHttpClient(new \GuzzleHttp\Client());

Mit der Variable $firebase kann nun auf die Datenbank zugegriffen werden und mit $client können Nachrichten versendet werden. Die json Datei und den apiKey findet man in der https://console.firebase.google.com/. Dort unter Deine App >> Projekteinstellungen >> Cloud Messaging ist der API Key und unter Deine App >> Projekteinstellungen >> Dienstkonten kann man sich einen privaten Schlüssel generieren lassen. Diesen dann entweder im gleichen Ordner wie die backend.php ablegen oder wie im Beispiel im Ordner secret. Wichtig ist das die Datei keinen entsprechende Zugriffsrechte hat, damit niemand diese über den Webserver auslesen kann. Das folgende Beispiel liest Elemente aus der Tabelle ‘Todos’ aus. Weitere Informationen wie ihr mit firebase-php arbeiten könnt, findet ihr unter: https://github.com/kreait/firebase-php

<?php

require ‘backend.php’;

$todos = $database->getReference(‘todos’)->orderByKey()->getSnapshot()->getValue();

foreach ($todos as $key => $value) {
echo $key.’ - ‘.$value[‘title’].’ (‘.$value[‘description’].’)\n’;
}

Verschicken kann man dann eine solche ‘Aufgabe’ mit:

<?php
$note = new Notification($title, $message’);
$note->setIcon(‘notification_icon_resource_name’)->setSound(“default”)->setBadge(1);

$message = new Message();
$message->addRecipient(new Topic(‘todos’));
$message->setNotification($note)->setPriority(“high”)->setTimeToLive(223200);

$response = $client->send($message);

In dem Beispiel wird die Nachricht nur an die Clients verteilt, welche sich auf das Topic ‘todos’ subscribte haben. Hier kann man aber auch z.B. devices auswählen oder an alle verschicken. Mehr dazu unter: https://github.com/Paragraph1/php-fcm Ob das Senden an FCM erfolgreich war kann man mit

$response->getStatusCode()

prüfen. Dabei sagt das Ergebnis aber nur aus ob die Nachricht an FCM übermittelt wurde, aber nicht ob die Clients diese erfolgreich erhalten haben.

Mit dem folgende Script kann man eine war Datei mit Jenkins Pipeline auf einem Tomcat deployen. Für das deployen mit curl auf einem tomcat wird ein User mit der Rolle manager-script benötigt.

node {
def devHost = ‘localhost’
// Mark the code checkout ‘stage’….
stage(‘Checkout’) {
checkout changelog: false, poll: true, scm: [$class: ‘GitSCM’, branches: [[name: ‘/branchname’]], doGenerateSubmoduleConfigurations: false,
extensions: [[$class: ‘CloneOption’, depth: 2, noTags: true, reference: ‘’, shallow: true, timeout: 15]], submoduleCfg: [],
userRemoteConfigs: [[credentialsId: ‘credentialsId’, url: ‘giturl’, name: ‘origin’, refspec: ‘+refs/heads/branchname:refs/remotes/origin/branchname’]]]
}
// Mark the code build ‘stage’….
stage(‘Deploy’) {
sh “mvn clean package”
deploy(“target/.war”, devHost, “/serverpath”)
}
stage(‘Archive’) {
archive ‘target/.war,target/**/\failsafe*/,target//*surefire*/**’
}
}
// Deploy file to tomcat
def deploy(file, host, context) {
sh “curl -v -u username:password -T ${file} ‘http://${host}:8080/manager/text/deploy?path=${context}&update=true’”
}

Checkout: Beim checkout wird nur eine Schatten Kopie mit einer Tiefe von 2 vom Ziel Branch heruntergeladen. Das reduziert die Zeit für den checkout. Bei einem

checkout scm

werden hingegen alle branches und auch die History des aktuellen Branches komplett heruntergeladen. Dies wird an dieser Stelle aber nicht benötigt. Deploy Stage: Nach dem bauen wird mittels curl einfach die war Datei auf dem Tomcat deployed. Was noch fehlt ist eine Prüfung ob das deployen erfolgreich war und das Neustarten des Tomcats falls nicht. Die Prüfung kann man mit curl oder wget machen und das Neustarten mit Hilfe einer ssh Verbindung auf den Tomcat.

Inzwischen ist Ionic 2 in der RC3 Version vorhanden. Aufgrund von Änderungen zwischen RC0, RC2 und RC3 sowie einigen Änderungen bei firebase und angularfire2, sind leider die meisten Beispiele im Internet nicht mit RC3 kompatibel.

Ionic Projekt

Solltet ihr bisher ionic noch nicht installiert haben, könnt ihr das mit dem folgenden Befehl machen: sudo npm install -g ionic cordova Falls ihr noch kein npm und node installiert habt, am besten die aktuelle Version installieren. Danach könnt ihr wie folgt starten: ionic start NamederAnwendung blank –v2 Danach dann noch ios (falls ihr auf mac arbeitet) und android hinzufügen:

ionic platform add ios && ionic platform add android

Nun könnt ihr die app mit dem folgenden Befehl unter android testen. Es empfiehlt sich das Testen immer im Emulator oder auf einem echten Device vorzunehmen, da für das login bei facebook und google cordova Plugins verwendet werden - welche untern “ionic serve” nicht beachtet werden:

ionic run android

Hinweis: Falls in der package.json > “@ionic/app-scripts”: “0.0.45”, steht. Bitte den Hinweis am Ende der Seite beachten - Firebase is not defined.

Firebase

Unter https://console.firebase.google.com/ erstellt ihr euch eine neue Anwendung. Am besten den geichen Namen wie der Name für die App. Danach unter Authentication >> Anmeldemethoden bei Google und Facebook auf editieren klicken und die Anmeldemethoden aktivieren. Für Facebook benötigt ihr die appId und appSecret, da wir aber noch keine Facebook App erstellt haben - dort aktuell nur einen Platzhalter eintragen. Danach unter Einstellungen/Projekteinstellungen gehen (findet man beim klick auf das Zahnrad oben links) und auf “Firebase zu meiner WebApp hinzufügen” klicken. Danach erscheinen die Keys für eure Firebase Einstellungen:

const firebaseConfig = {
apiKey: “Key”,
authDomain: “authdomain.firebaseapp.com”,
databaseURL: “https://autdomain.firebaseio.com",
storageBucket: “storage.foo.com”,
};

Diese werden in eine Temporäre Textdaten kopiert, da sie später benötigt werden. Die messageId Variable wird nicht benötigt - wer Firebase Messaging verwenden möchte, kann das mit Ionic2 Push machen.

Facebook

Zuerst unter https://developers.facebook.com/apps eine neue App erstellen. Danach dann in der App unter “Produkt hinzufügen” auf “Facebook Login” klicken. Bei “Gültige OAuth Redirect URIs” die Url welche ihr unter von https://console.firebase.google.com/ >> Authentication >> Anmeldemethoden >> Facebook findet eintragen. Danach unter Einstellungen für eure Facebook App gehen und auf “Platfform hinzufügen” klicken. Daher erkläre ich im folgenden wie man mit ionic2 und firebase einen Google Login/SignIn und Facebook Login/SignIn realisieren kann: Bei “Google Play Package-Name” tragt ihr die id aus eurer config.xml im root Ordner eures Ionic Projektes ein.

            var provider = firebase.auth.GoogleAuthProvider.credential(userData.idToken);

             firebase.auth().signInWithCredential(provider)
              .then((firebaseData) => {
                console.log("Firebase success: " + JSON.stringify(firebaseData));
                observer.next();
              })
              .catch((error) => {
                console.log("Firebase failure: " + JSON.stringify(error));
              });
             })
         .catch((error) => {
             console.log("Firebase failure: " + JSON.stringify(error));
         });
      })
   })
});

Auf den NAS Speichern von Qnap ist es möglich Docker Container laufen zu lassen. Dadurch kann man auch Gitbucket auf dem NAS laufen lassen und so sein eigenes “github” im Netzwerk haben. Gitbucket ist eine Webanwendung welche die Funktionen von Github beinhaltet (minimale Funktionen). Aber Schritt für Schritt. Zuerst wählt man auf dem NAS Speicher die Anwendung “Container Station” und wählt neuen Container erstellen. Dann verwendet man die Suche und sucht nach “hiono/gitbucket”. Beim erstellen am besten immer den Tab “Docker Hub” verwenden, damit man die aktuellste Version verwendet. Es ist zu empfehlen direkt eine Version auszusuchen anstatt latest. Dazu aber später mehr. Wichtig bei den Daten sind dann zwei Einstellungen unter “Erweiterte Einstellungen”:

• Netzwerk - hier empfiehlt es sich zwei feste Ports zu vergeben. Einen für die Weboberfläche und einen für SSH. Wenn diese fest definiert werden, dann müsst ihr später bei einem Wechsel nicht immer die Ports anpassen
• Freigabeordner - hier müsst ihr den Pfad “/var/gitbucket” mit einem Verzeichnis auf eurem Nas Speicher verbinden. Dadurch könnt ihr später die Docker Container austauschen ohne die Daten migrieren zu müssen. Da die Daten dann nicht im Container liegen, sondern als Volume gemountet werden.

Danach einfach erstellen und nutzen. Wie updatet man auf eine neue Version von gitbucket?

1. Alten Container stoppen
2. Neues Image von Docker Hub mit der letzten Version auswählen
3. Beim Image die gleichen Ports für Netzwerk wie beim alten Container eintragen
4. Beim Image den gleichen Freigabe Ordner wie beim alten Container eintragen
5. Container erstellen und starten
6. Prüfen
7. Alten Container löschen oder automatisches Starten deaktivieren, falls man sich nicht sicher ist.

Das Docker Image ist das folgende: https://hub.docker.com/r/hiono/gitbucket/

Im folgenden erkläre ich wie man seine lokalen Ordner mit einem einfachen Script mittels rsync auf ein NAS sichern kann. Zudem wird das Script nur ausgeführt wenn ich mich im richten WLAN befinde. Zuerst benötigt man dafür auf dem NAS so genannte “Module” für Rsync. Das sind freigegebene Ordner. Diese kann man sich mit ssh unter /etc/rsyncd.conf anschauen oder bei qnap unter Privilegieneinstellungen >> Freigabe-Ordner (shared folders). Das editieren der rsyncd.conf ist nicht zu empfehlen, da diese z.B. bei der Vergabe eines neuen Passworts für rsync automatisch zurückgesetzt wird bzw. durch Firmware updates auf den meisten NAS Speichern verändert werden könnte. Bei Qnap könnt ihr Rsync unter der App “Sicherungsstrategien” oder “Hybrid Backup - Sync beta” aktivieren. Dort wird auch das Passwort vergeben. Alternativ kann auch ein SSH User verwendet werden, jedoch ist bei Qnap das nur mit dem Admin User möglich. Ansonsten muss bei Qnap ein anderer SSH Server installiert werden. Aber nun zum eigentlichen rsync aufruf. Zum Testen könnt ihr folgendes verwenden:

rsync -aPuvb –modify-window=1 –exclude “.@__thumb” –delete –backup-dir ‘../backupOrdnerAufDerNasfuergeloeschteDateien’ –stats – /PfadZumOrdnerWelcherAufDerNasGesichertWerdenSoll/ rsyncusername@NAS-IP-ADRESSE::SharedFolderNameAufDerNAS/beiBedarfHierUnterverzeichnisseAngeben

Nach der Eingabe kommt eine Meldung mit der Frage nach dem Passwort für rsync, welches Ihr zuvor eingerichtet habt. Falls SSH verwendet werden soll, dann

rsyncusername@NAS-IP-ADRESSE::SharedFolderNameAufDerNAS/beiBedarfHierUnterverzeichnisseAngeben

mit dem folgendem ersetzten

username@NAS-IP-ADRESSE:/PfadAufDerNasZuEuremZielVerzeichniss

Was die Parameter bedeuten wird kurz erklärt:

• –modify-window=1 => Bei Windows und Samba kann es zu Problemen mit der Übertragungszeit kommen, hierdurch wird Unschärfe ermöglicht. Dadurch wird verhindert das die Datei auf der NAS neuer ist wie die Lokale
• –exclude “.@__thumb” => Beachtet automatisch erstelle Thumbmails nicht, sehr praktisch bei vielen Bilder Übertragungen
• -b –delete –backup-dir ‘../BackupVerzeichnis’ => Es werden lokal gelöschte Dateien auch auf dem Zielsystem gelöscht. Aber zur Sicherheit in den angegeben Ordner verschoben (-b)
• –stats => Ausgabe der Statistik bezüglich der Änderungen an den Dateien
• -u => überspringt Dateien, die im Ziel neuer sind als in der Quelle
• -P => Fortschrittsanzeige und Fortsetzung des Transfers bei Abbruch
• -v => zeigt während des Synchronisierens alle ausgeführten Schritte an

Damit das ganze auch ohne Passwort funktioniert muss man das noch mit

–password-file=filewithpassowrd.txt

erweitern. In diese Datei schreibt man dann das Rsync Passwort und setzt die Lese und Schreibrechte für die Datei entsprechend so das nur das Script die Datei lesen kann. Damit nicht ständig versucht wird einen Server anzufragen obwohl man nicht zu Hause im eigenen WLAN ist - kann man das Script um folgendes erweitern:

essid=$(iwgetid -r)
echo $essid;
if [ “$essid” = “NameDeinesWlansZuHause ]
then

#rsync staff
else
echo “Wrong WLAN”
fi

Das ganze Beispiel Script findet ihr hier unter https://gist.github.com/lightszentip/9558283d339c4cb19d5b691fae0e060a Um das script automatisch ausführen zu lassen bietet sich ein crontab mit der Ausgabe in eine LogDatei an “>> naslogresult.log“

Die neue Pipeline Funktion von Jenkins kann mit Jenkins 1.x und 2.x verwendet werden. Bei Jenkins 2.x gibt es aber auch noch ein Plugin um die einzelnen Stages in einer View zu visualisieren. Für die Pipeline gibt es auch einen Snippet Generator unter http://localhost:8080/jenkins/job/Pipelinetest/pipeline-syntax/. Mit dessen Hilfe kann man für die meisten Anwendungsfälle Snippets generieren und diese dann nach den eigenen Anforderungen anpassen. Der Beispiel Code für einen Github checkout und Maven aufruf sieht dabei wie folgt aus:

node {
// Mark the code checkout ‘stage’….
stage ‘Checkout’
// Get some code from a GitHub repository
git url: ‘https://github.com/jglick/simple-maven-project-with-tests.git'
// Get the maven tool.
// ** NOTE: This ‘M3’ maven tool must be configured
// ** in the global configuration.
def mvnHome = tool ‘M3’
// Mark the code build ‘stage’….
stage ‘Build’
// Run the maven build
sh “${mvnHome}/bin/mvn -Dmaven.test.failure.ignore clean package”
step([$class: ‘JUnitResultArchiver’, testResults: ‘*/target/surefire-reports/TEST-.xml’])
}

Dabei sieht man auch die Änderungen bei Jenkins 2, das Thirdparty Komponenten wie Maven über Variablen und nicht mehr über Pfad Angaben in der Konfiguration gemanagt werden. Die „stage“ aufrufe bilden dabei die einzelnen Schritte welche auch in der Stage View sichtbar sind.

Wer sich mit Slim und Ionic ein kleine App und Rest Api bauen möchte, kann schnell mit dem Thema CORS in Kontakt kommen. Besonders beim testen auf der lokalen Maschine. Damit es auch lokal funktioniert. Müssen die folgenden Zeilen am Anfang der index.php hinzugefügt werden (am besten ganz oben):

header(‘Access-Control-Allow-Origin: *’);
header(“Access-Control-Allow-Headers: Origin, Content-Type, Authorization”);
header(“Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS, DELETE”);

Dabei kann man natürlich auch die Freigabe auf bestimmte Domains einschränken. Falls man diese drei Zeilen jedoch nicht hinzufügt, erhält man bei einem http.get(…) die folgende Fehlermeldung:

{“_body”:{“isTrusted”:true},”status”:0,”ok”:false,”statusText”:””,”headers”:{},”type”:3,”url”:null}

Im folgenden Beitrag beschreibe ich die Installation eines Jenkins 2.x in einem Tomcat8. Es ist auch möglich den Jenkins ohne Tomcat laufen zu lassen.

Schritt 1

Installation Tomcat8 unter Linux mit

sudo apt-get install tomcat8

alternativ kann auch die aktuelle Version unter https://tomcat.apache.org/download-80.cgi heruntergeladen werden und entpackt werden. Dieses Vorgehen ist für Windows zu empfehlen. Unter Linux ist der Tomcat nach der Installation unter /var/lib/tomcat8/ zu finden.

Schritt 2

Damit Jenkins im Tomcat richtig starten kann, muss JENKINS_HOME im Tomcat Environment gesetzt werden. Alternativ kann JENKINS_HOME auch als Umgebungsvariable gesetzt werden, was aber das betreiben mehrerer Jenkinses auf einem Server verhindert. Der folgende Code wir in der Datei conf/context.xml eingefügt:

Das Plugin ist jetzt auch 4.4.x kompatibel :-) Die Neue Version findet ihr unter https://gnetos.de/projekte/wp-plugin-monats-jahresspruche-time-slogan-plugin.html (V 2.1.0). Parallel reiche ich es bei Wordpress als Plugin ein.