S3 und Swift mit dem Ceph Object Gateway (radosgw)

 Object Gateway ist eine Objektspeicher-Schnittstelle, welche Anwendungen eine RESTful HTTP Schnittstelle zum Ceph Object Store zur Verfügung stellt.

Es werden 2 Schnittstellen unterstützt:

  • S3-Kompatibilität: Stellt eine Objektspeicherfunktionalität mit einer Schnittstelle bereit, die zum größtenteils mit der Amazon S3 RESTful API kompatibel ist.
  • Swift-Kompatibilität: Stellt die Objektspeicherfunktionalität mit einer Schnittstelle bereit, die zum größtenteils der OpenStack Swift API kompatibel ist.

Das Ceph Object Storage verwendet den RadosGW Daemon für die Interaktion mit dem Ceph Storage-Cluster. Als Backend kann hierfür das gleiche Ceph Storage Cluster verwendet werden wie für das Ceph Filesystem oder das Ceph Block Device.

Seit dem Ceph Release Jewel ist es nun auch möglich in einer MultiSite Konfiguration in die Nicht-Master-Zonen zu schreiben. Die Synchronisation der einzelnen Zonen funktioniert Out-of-the-box. Auf zusätzliche Agenten wird seit dem Jewel Release verzichtet.

Eine ausführliche Dokumentation für die Einrichtung eines MultiSite RADOSGateway findet man natürlich in der offiziellen Dokumentation oder auch bei uns in der Ceph Schulung.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

Exchange SSL Error

Wir haben unsere interne Windows CA von SHA1 auf SHA256 umgestellt und alle Zertifikate erneuert. Soweit so gut, doch nach einem Neustart der Exchange Server konnten sich unsere Mailclients nicht mehr mit dem Exchange verbinden und OWA gab nach dem Login nur eine weiße Seite zurück.

In der Ereignisanzeige fanden wir folgenden Fehler:

An error occurred while using SSL configuration for endpoint
0.0.0.0:444. The error status code is contained within the returned
data.

Um dieses Problem zu lösen sind wir wie folgt vorgegangen:

netsh http show sslcert

IP:port                      : 0.0.0.0:444
Certificate Hash             :
Application ID               : {4dc34hge........}
Certificate Store Name       : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Dieser Befehl zeigt die gebundenen Zertifikate an. Das relevante hierbei ist das Zertifikat für 0.0.0.0:444.
Dieses müssen wir nun löschen und neu zuordnen. Die Ausgabe kopieren wir uns vorher in ein Textfile.

netsh http delete sslcert ipport=0.0.0.0:444
iisreset

Nun brauchen wir den Hash aus unserem neuen Zertifikat und die Application ID, die wir uns in das Textfile
kopiert haben.

netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXX  appid=”{XXXXXXX}”
iisreset

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

How to configure a Windows machine to allow file sharing with a DNS Alias

Last week we moved our cifs share from a Netapp filer to a Ceph disk mounted on a virtual windows server handling the share. After that, we configured the share and changed the DNS Alias to the new IP on the Windows server. Now every Windows and Mac client is able to mount the new share with the new dns alias – except the Linux clients, which got some errors like:

mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

On Windows machines file sharing can work via the computer name, with or without full qualification, or by the IP Address. By default however, file sharing will not work with DNS aliases (in our case just the Linux clients). To enable filesharing to work with DNS aliases, you must make registry changes and reboot the machine.

The solution for this is setting “DisableStrictNameChecking” to allow other machines to use filesharing via the DNS Alias. This change will allow other machines on the network to connect to the machine using any arbitrary hostname:

Add the value “DisableStrictNameChecking” of type DWORD and set it to 1:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

On Windows Server 2008 R2:
Add the value “DnsOnWire” of type DWORD and set it to 1

HKLM\SYSTEM\CurrentControlSet\Control\Print

This change will not allow a machine to connect to itself via a hostname. For that you need “BackConnectionHostNames” to allow a server machine to use filesharing with itself via the DNS Alias.

Add a new Multi-String Value “BackConnectionHostNames”

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.

Note: Type each host name on a separate line.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

Migration auf Exchange Server 2013

Nachdem wir als Mailserver schon immer Microsoft Exchange im Einsatz haben und wir bisher auch zufrieden damit sind, hatten wir uns für die Migration von Exchange 2010 auf Exchange 2013 entschieden.

Hier einige Neuerungen im Überblick:

  • Es wird kein MAPI-Protokoll mehr verwendet, sondern bindet auch interne Clients per RPC über HTTPS (Outlook Anywhere) an die Postfächer an.
  • Die Serverrollen Hub-Transport und Unified-Messaging hat Microsoft gestrichen. Die Funktionen übernehmen die Postfach- und die Clientzugriffserver.
  • Die Exchange-Verwaltungskonsole und die webbasierte Exchange-Systemsteuerung von Exchange Server 2010 wurde zur neuen Exchange Administrative Console (EAC) zusammengefasst. Die Bezeichnung ist nun Exchange-Verwaltungskonsole, hat aber nichts mehr mit der alten Konsole in Exchange Server 2010 gemeinsam.
  •  Der Postfachserver umfasst alle Serverkomponenten aus Exchange 2010:  Clientzugriffsprotokolle, Transportdienst, Postfachdatenbanken und Unified Messaging. Der Postfachserver verarbeitet alle Vorgänge für die aktiven Postfächer auf dem lokalen Server.
  • Für den E-Mail-Transport in Exchange Server 2013 sind die drei Dienste Front-End Transport Service (FET), Hub Transport Service (HT) und Mailbox Transport Service (MT) zuständig. Diese Dienste gehören jetzt zur Postfachserver-Rolle. Hub-Transport-Server gibt es nicht mehr.
  • Erhöhte Sicherheit und integrierter Virenschutz.

Diese Systemvoraussetzungen sind zu beachten:

  • Der Exchange Server 2013 kann in Organisationen mit Exchange Server 2007 SP3 und Exchange Server 2010 SP3 betrieben werden. Exchange Server 2003 ist nicht kompatibel zu Exchange Server 2013.
  • Als Betriebssystem muss Windows Server 2008 R2 oder Windows Server 2012 laufen.
  • Die Domäne und die Gesamtstruktur muss mindestens mit der Funktionsebene Windows Server 2003 betrieben werden.
  • Exchange Server 2013 nutzt IPv6 und IPv4 zur Kommunikation. Auch wenn Sie im Netzwerk IPv6 nutzen, muss IPv4 aktiv sein.

Da es schon viele gute Howtos im Netz gibt, spar ich mir das und verweise hier auf 3 Seiten die mich bei der Migration sehr gut unterstützt haben.

John Lose – Link
Frank Carius – Link
Frankys Web – Link

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

Bareos (Backup Archiving Recovery Open Sourced)

Wir haben seit sehr langer Zeit das OpenSource Tool Bacula für unsere Backups verwendet,
womit wir auch in der Vergangenheit sehr zufrieden waren. Da aber nur noch die kommerzielle
Version wirklich weiterentwickelt wird, haben wir uns für einen Wechsel zu Bareos entschieden.

http://www.bareos.org/assets/images/9/Logo_signet_64x64-4e199499.png

Bareos (Backup Archiving Recovery Open Sourced) ist eine zuverlässige,
netzwerkübergreifende Open Source Software zur Sicherung, Archivierung und
Wiederherstellung von Daten aller gängigen Betriebssysteme.

Im Jahr 2010 hervorgegangen aus dem Projekt Bacula wurde und wird Bareos als Fork aktiv
weiterentwickelt und mit vielen neuen Features angereichert.

So bietet Bareos heute unter anderem eine LTO Hardware-Verschlüsselung, eine
Bandbreitenbegrenzung und neue praktische Konsolen-Kommandos.

Der Quellcode von Bareos ist auf https://github.com/bareos/ verfügbar und steht unter
der Lizenz AGPL v3. Zudem stellt Bareos fertige Pakete über Repositories für die
wichtigsten Linux Distributionen sowie für Windows bereit.

Die Umstellung von Bacula auf Bareos funktionierte ohne Probleme und es macht für uns bisher
einen sehr guten Eindruck.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.