Support-Chat für die eigene Website – mit Rocket.Chat

Rocket.Chat bietet neben der umfangreichen Vernetzung bestehender Teams auch ein ganz besonderes Feature, den Supportchat. Dieser eignet sich für Websitenbetreiber, um direkt und ohne Wartezeit mit dem Besucher kommunizieren zu können. In diesem Artikel gehe ich einmal auf die Einrichtung und Einbindung eines solchen Supportchats auf der eigenen Website ein.

Installation
Zu Beginn muss Rocket.Chat installiert und auf einer Public-Domain erreichbar gemacht werden. Diese Domain muss auch für die weitere Verwendung bei der Einrichtung von Rocket.Chat angegeben werden.

Einrichtung
Die Einrichtung ist mit wenigen Klicks erledigt. Wichtig: In jedem Fall sollte die manuelle Freischaltung des Userkontos (der Support-Kollegen) erfolgen, anderenfalls kann sich jeder einfach registrieren und den Support-Chat als Dritter auch unterstützen. Zu finden ist diese Option unter Administration->Accounts->Registration “

Einbindung
Nun geht es eigentlich schon zum letzten Schritt, der Einbindung auf die Website. In der Administrationsoberfläche des Livechats ist nun der Quellcode zum Einbetten des eigenen Iframes vorbereitet. Dieses Script muss bei auf jeder Webiste auftauchen, auf der der Supportchat erscheinen soll. Das Ganze sieht dann in etwa so aus.

<!-- Start of Rocket.Chat Livechat Script -->
<script type="text/javascript">
(function(w, d, s, u) {
 w.RocketChat = function(c) { w.RocketChat._.push(c) }; w.RocketChat._ = []; w.RocketChat.url = u;
 var h = d.getElementsByTagName(s)[0], j = d.createElement(s);
 j.async = true; j.src = 'https://222-rocketchat-63af3-web.nws.netways.de/packages/rocketchat_livechat/assets/rocket-livechat.js';
 h.parentNode.insertBefore(j, h);
})(window, document, 'script', 'https://222-rocketchat-63af3-web.nws.netways.de/livechat');
</script>
<!-- End of Rocket.Chat Livechat Script -->

Am Ende kann noch etwas am Erscheinungsbild geschraubt werden, damit sich der Chat sauber in die eigene Seite einfügt. Fertig! Um weitere Agents als Supportkollegen in den Chat aufzunehmen, müssen diese noch in der Admin-Bereich des Livechats als “Livechat-Agents” hinzugefügt werden.

Wie werden die Anfragen verteilt?
Falls mehrere Kollegen im Livechat zur Verfügung stehen, so werden die Anfragen Round Robin an diese verteilt. Wenn kein Kollege online ist, fordert der Livechat etwas Geduld vom Besucher und schickt eine E-Mail an den Websitenbetreiber mit den eingegebenen Kontaktdaten.

Aus Kundensicht zu testen ist unser toller Livechat in seiner vollen Pracht auf unserer NWS-Website (wir freuen uns über jede Anfrage). Dort kann selbiger auch direkt als eigene Instanz für 30 Tage völlig kostenfrei und unverbindlich getestet werden – ohne Einschränkungen!

Unsere Kunden profitieren stets von den aktuellsten Software-Versionen, höchster Verfügbarkeit, freundlichem Support und fairen Preisen. Bei allen unserer NWS-Instanzen erhalten Sie natürlich vollen Administrationszugriff und teilen sich die Applikation nicht mit anderen Kunden. Alle Applikationen stehen binnen Sekunden ready-to-use zur Verfügung.

Übrigens, für WordPress und andere Applikationen gibt es bereits fertige Rocket.Chat Livechat Plugins.

Interesse? erfahren Sie mehr über unsere Rocket.Chat-Pakete

 

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

NETWAYS Web Services: GitLab CE Hosting

This entry is part of 5 in the series NETWAYS Web Services

GitLab CE HostingGitLab CE (Community Edition) ist die frei verfügbare Variante von GitLab, welche alle wichtigen Features von GitLab in einer Open Source Version vereint. GitLab bietet eine webbasierte Oberfläche für Softwareprojekte auf Basis der Versionsverwaltung git. Dazu verfügt GitLab über diverse Management und Bug-Tracking-Funktionalitäten, sowie mit GitLab CI ein System zur kontinuierlichen Integration.

NETWAYS bietet das Hosting von GitLab CE in unserer NETWAYS Web Services an. Wir übernehmen hier nicht nur die Installation und Konfiguration, sondern auch den kompletten Betrieb inkl. regelmäßiger Updates auf die aktuellste Version. Unser Angebot wird verteilt über zwei Rechenzentren in Nürnberg gehostet und betrieben. Somit stellen wir einen sicheren und zuverlässigen Service an einem (sehr schönen) Standort in Deutschland zur Verfügung.

GitLab CE

Alle GitLab CE Instanzen laufen isoliert in einem eigenen Container und alle nötigen Ressourcen sind exklusiv für Ihr Projekt reserviert. Und bei uns sind die GitLab Runner schon mit dabei!

Und wie gewohnt bei NWS – Sie können GitLab CE bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

 

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Contributing to projects on GitHub

GitHub Logo

Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.

The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.

Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:


git clone git@github.com/dgoetz/icinga2.git

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:


cd icinga2/
git remote add upstream git@github.com:icinga/icinga2.git

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:


git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.


vi itl/plugins-contrib.d/network-components.conf
vi doc/10-icinga-template-library.md
git add itl/plugins-contrib.d/network-components.conf doc/10-icinga-template-library.md
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:


git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.

GitHub pull request

Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:


vi doc/10-icinga-template-library.md
git add doc/10-icinga-template-library.md
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:


git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:


git checkout master
git pull upstream master
git checkout -b fix/check-bar
...
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

NETWAYS Web Services: Rocket.Chat Hosting

This entry is part 1 of 5 in the series NETWAYS Web Services

Rocket.Chat HostingRocket.Chat ist eine Open Source Chat-Lösung, die sich als offene Slack-Alternative positioniert. Mit Rocket.Chat kann man ganz einfach Chaträume für viele gleichzeitige Nutzer erstellen, wodurch die Kommunikation zu unterschiedlichsten Themen, Projekten und in Teams und Gruppen ermöglicht wird.

Für die direkte Kommunikation zwischen zwei Benutzern stehen private Channels zur Verfügung, die auch sicher verschlüsselt werden. Daneben bietet Rocket.Chat noch File Sharing, einen Helpdesk Chat für die direkte Kommunikation mit Ihren Kunden, Video-Chat und Screensharing und native Anwendungen und mobile Apps für jedes Betriebssystem und Mobilgerät.

Über die NETWAYS Web Services können wir Rocket.Chat Instanzen in verschiedenen Größen für alle Einsatzzwecke zur Verfügung stellen – natürlich voll von uns gemanaged.

Rocket.Chat Hosting

Und zum guten Schluss – Sie können Rocket.Chat bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Monthly Snap March > NETWAYS Web Services, Jitsi, ReactOS, Ceph, Braintower, OSDC, Graylog, Elastic{ON], Timelion, Icinga Director, Puppet

Tim began with a simple video chat jitsi-meets  and Alexander continued with his experiences with ReactOS.

Then Deniz wrote about Crush Maps in Ceph while Isabel presented the latest Shop Highlights such as AKCP sensorProbe 2, the Braintower software version 3.5.0 and some new STARFACE Services.

Then Martin announced our new platform NETWAYS Web Services and Gabriel analysed the differences between OwnCloud and Nextcloud.

Jean gave us an insight in the Icinga Buildserver, Version 3, while Julia started the countdown for the OSDC 2017 and presented the fixed program. Thomas Widhalm and Nicole reviewed the Elastic{ON] in San Francisco.

Blerim then described the Kibana add-on Timelion and Markus Waldmüller showed benefits given by the Icinga Director.

On events, Julia presented the programme and sponsors for the OSDC in May and announced our new training sessions for GRAYLOG.

Later in April, Ronny looked at multi-zone notifications in Icinga 2 while Gunnar presented ControlPlane.

Furthermore, Michael managed Elasticsearch, Kibana & icingabeat with Puppet and Lennart began with the first part of automated Monitoring with Puppet.

Last, but not least, Vanessa told about the Akademika 2017, where we’re serching for nice colleagues.

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Manage Elasticsearch, Kibana & icingabeat with Puppet

A while back I’ve already looked into the Elastic Stack 5 Beta release and the beats integration. Time flies and the stable release is here. Blerim announced the icingabeat 1.0.0 release last week, and so I was looking into a smooth integration into a Vagrant box here.

The provisioner uses Puppet, which Puppet modules could be used here? I’m always looking for actively maintained modules, best by upstream projects which share the joy of automated setups of their tools with their community.

 

Elastic and Kibana Puppet Module

The Elastic developers started writing their own Puppet module for Kibana 5.x. Previously I’ve used community modules such as puppet-kibana4 or puppet-kibana5. puppet-elasticsearch already supports 5.x for a while, that works like a charm.

Simple example for a low memory Elasticsearch setup:

class { 'elasticsearch':
  manage_repo  => true,
  repo_version => '5.x',
  java_install => false,
  jvm_options => [
    '-Xms256m',
    '-Xmx256m'
  ],
  require => Class['java']
} ->
elasticsearch::instance { 'elastic-es':
  config => {
    'cluster.name' => 'elastic',
    'network.host' => '127.0.0.1'
  }
}

Note: jvm_options was released in 5.0.0.

 

Default index pattern

If you do not define any default index pattern, Kibana greets you with a fancy message to do so (and I have to admit – i still need an Elastic Stack training to fully understand why). I wanted to automate that, so that Vagrant box users don’t need to care about it. There are several threads around which describe the deployment by sending a PUT request to the Elasticsearch backend.

I’m using a small script here which waits until Elasticsearch is started. If you don’t do that, the REST API calls will fail later on. This is also required for specifying index patterns and importing dashboards. A Puppet exec timeout won’t do the trick here, because we’ll have to loop and check again if the service is available.

$ cat/usr/local/bin/kibana-setup
#!/bin/bash

ES_URL="http://localhost:9200"
TIMEOUT=300

START=$(date +%s)

echo -e "Restart elasticsearch instance"
systemctl restart elasticsearch-elastic-es

echo -e "Checking whether Elasticsearch is listening at $ES_URL"
until $(curl --output /dev/null --silent $ES_URL); do
  NOW=$(date +%s)
  REAL_TIMEOUT=$(( START + TIMEOUT ))
  if [[ "$NOW" -gt "$REAL_TIMEOUT" ]]; then
    echo "Cannot reach Elasticsearch at $ES_URL. Timeout reached."
    exit 1
  fi
  printf '.'
  sleep 1
done

If you would want to specify the default index pattern i.e. for an installed filebeat service, you could something like this:

ES_INDEX_URL="$ES_URL/.kibana/index-pattern/filebeat"
ES_DEFAULT_INDEX_URL="$ES_URL/.kibana/config/5.2.2" #hardcoded program version

curl -XPUT $ES_INDEX_URL -d '{ "title":"filebeat", "timeFieldName":"@timestamp" }'
curl -XPUT $ES_DEFAULT_INDEX_URL -d '{ "defaultIndex":"filebeat" }'

One problem arises: The configuration is stored by Kibana program version. There is no symlink like ‘latest’, but you’ll need to specify ‘.kibana/config/5.2.2’ to make it work. There is a certain requirement for pinning the Kibana version, or finding a programatic way to automatically determine the version.

 

Kibana Version in Puppet

Fortunately the Puppet module allows for specifying a version. Turns out, the class validation doesn’t support package revision known from rpm (“5.2.2-1”). Open source is awesome – you manage to patch it, apply tests and after review your contributed patch gets merged upstream.

Example for Kibana with a pinned package version:

$kibanaVersion = '5.2.2'

class { 'kibana':
  ensure => "$kibanaVersion-1",
  config => {
    'server.port' => 5601,
    'server.host' => '0.0.0.0',
    'kibana.index' => '.kibana',
    'kibana.defaultAppId' => 'discover',
    'logging.silent'               => false,
    'logging.quiet'                => false,
    'logging.verbose'              => false,
    'logging.events'               => "{ log: ['info', 'warning', 'error', 'fatal'], response: '*', error: '*' }",
    'elasticsearch.requestTimeout' => 500000,
  },
  require => Class['java']
}
->
file { 'kibana-setup':
  name => '/usr/local/bin/kibana-setup',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/kibana-setup",
}
->
exec { 'finish-kibana-setup':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/kibana-setup",
  timeout => 3600
}

 

Icingabeat integration

That’s fairly easy, just install the rpm and put a slightly modified icingabeat.yml there.

$icingabeatVersion = '1.0.0'

yum::install { 'icingabeat':
  ensure => present,
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-$icingabeatVersion-x86_64.rpm"
}->
file { '/etc/icingabeat/icingabeat.yml':
  source    => 'puppet:////vagrant/files/etc/icingabeat/icingabeat.yml',
}->
service { 'icingabeat':
  ensure => running
}

I’ve also found the puppet-archive module from Voxpupuli which allows to download and extract the required Kibana dashboards from icingabeat. The import then requires that Elasticsearch is up and running (referencing the kibana setup script again). You’ll notice the reference to the pinned Kibana version for setting the default index pattern via exec resource.

# https://github.com/icinga/icingabeat#dashboards
archive { '/tmp/icingabeat-dashboards.zip':
  ensure => present,
  extract => true,
  extract_path => '/tmp',
  source => "https://github.com/Icinga/icingabeat/releases/download/v$icingabeatVersion/icingabeat-dashboards-$icingabeatVersion.zip",
  checksum => 'b6de2adf2f10b77bd4e7f9a7fab36b44ed92fa03',
  checksum_type => 'sha1',
  creates => "/tmp/icingabeat-dashboards-$icingabeatVersion",
  cleanup => true,
  require => Package['unzip']
}->
exec { 'icingabeat-kibana-dashboards':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/share/icingabeat/scripts/import_dashboards -dir /tmp/icingabeat-dashboards-$icingabeatVersion -es http://127.0.0.1:9200",
  require => Exec['finish-kibana-setup']
}->
exec { 'icingabeat-kibana-default-index-pattern':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "curl -XPUT http://127.0.0.1:9200/.kibana/config/$kibanaVersion -d '{ \"defaultIndex\":\"icingabeat-*\" }'",
}

The Puppet code is the first working draft, I plan to refactor the upstream code. Look how fancy 🙂

Conclusion

Managing your Elastic Stack setup with Puppet really has become a breeze. I haven’t tackled the many plugins and dashboards available, there’s so much more to explore. Once you’ve integrated icingabeat into your devops stack, how would you build your own dashboards to correlate operations maintenance with Icinga alerts? 🙂

If you’re interested in learning more about Elastic and the awesome Beats integrations, make sure to join OSDC 2017. Monica Sarbu joins us with her talk on “Collecting the right data to monitor your infrastructure”.

PS: Test-drive the integration, finished today 🙂

 

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉