Dienstag, 26. April 2016

OpenStack Summit Austin - Zusammenfassung

OpenStack Summit Austin

Im folgenden befindet sich eine Zusammenfassung des ersten Tages meines Besuchs auf der OpenStack Summit in Austin. Zwecks der Übersicht habe ich mich nur auf einige Keynotes und besuchte Sessions fokussiert, welche aus meiner Sicht die wichtigen und aktuellen Themen aus der OpenStack Welt sehr gut wiederspiegeln.

Keynotes

Gartner

Die erste Präsentation der OpenStack Summit in Austin wurde von Gartner vorgetragen. Bestandteil dieser Präsentation war die Vorstellung des zwei Mode Modells, in welchem davon die Rede ist, dass in Zukunft alle Unternehmen sowohl den traditionellen Weg (ITIL, CMMI, COBIT) als auch den neuen Weg der IT (Devops, Automation) nutzen werden. Begründet wurde dies u.a. damit, dass Entwicklungsprozesse schlecht oder nur sehr langsam mit ITIL Vorgaben zu vereinbaren sind und es für jeden Modus unausweichliche Vorteile gibt. Der parallele Betrieb beider Moden ergibt sich dadurch, dass die Entwicklungs und Testumgebungen anders betrachtet werden als der Produktivbetrieb und somit parallel und unter Berücksichtung der jeweiligen Vorteile betrieben werden können. Dabei zeichnet sich ab, dass die Traditionellen Applikationen in Zukunft immer mehr in Richtung Cloud optimiert werden (z.B. angepasste Skalierung) und Neuentwicklungen sich langsam zu Produktivanwendungen (z.B. Hohe Verfügbarkeit) entwickeln.


Mirantis

Von Mirantis kam eine Zusammenfassung aus dem Bereich der Umsetzung von OpenStack Lösungen. Hierbei wurde auf eine Gartner Studie bzgl. Problemen bei Cloud Projekten verwiesen. Fehler beim Umsetzen der Prozesse sowie fehlende Motivation bei der Umsetzung waren hierbei die größten Rückschläge (~50%). Im diesem Rahmen wurde auch erklärt, wie es zu diesen Problemen kommt. Eine sehr schöner Vergleich wurde hierbei mit dem Prozess erläutert, wie die Enduser eine interne Cloud bestellen und sich selbst mit dem Einsatz OpenStack für eine Public Cloud entscheiden würden, da die internen Prozesse im Weg sind. Der Erfolg von OpenStack hängt zu 10% an OpenStack selbst, zu 90% allerdings an den Mitarbeitern und Prozessen im Unternehmen.


VW

Mario Müller von der VW hat den Einsatz und die elementare Notwendigkeit von OpenStack bei der VW Vorgestellt. Durch den Wachstum der nächsten Jahre in allen Bereichen wie z.B. Car-Configurator und den Elektroautos und den hierfür zur Verfügung gestellten Services ist es notwendig eine dynamische und günstige Lösung zu finden, welche die IT Infrastruktur neu erfindet. Durch das VW Commitment "Cloud first" wurden auch noch weitere Projekte der VW wie z.B. der Cloud Foundry Einsatz als Platform as a Service vorgestellt.



Übersicht ausgewählter Sessions

Key Requirements for OpenStack Backup and Recovery

Von Trilio Data wurde ein Backup-Restore Konzept für komplette OpenStack Umgebungen vorgestellt. Es handelt sich hierbei um eine Lösung welche auf dem Data Protection Service Raksha basiert und das Backup-Restore Konzept für den Enterprise Betrieb erweitert. Die Anbindung an Raksha ermöglicht es neben dem Backup von ganzen OpenStack-Umgebungen auch komplette persistente virtuelle Instanzen zu sichern und wieder herstzustellen. Ein weiterer Vorteil dieser Lösung ist, dass der Restore auch auf einer weiteren OpenStack Umgebung durchgeführt werden kann. Dies ermöglicht u.a. eine komplette und einfach zu realisierende Migration zwischen zwei OpenStack Installationen.


Performance Mesuring Tools for the Cloud

Im Bereich Perfomance wurde aus einem Mix von OpenStack Nutzern (RedHat, AWCloud, Intel und Dell) die gängisten Lösungen für Performance Analysen vorgestellt. Neben der Vorstellung von Rally, Cloud Bench SPECcloud und Perfkit wurden auch weitere Methoden und Möglichkeiten zur Auswertung von Performanceproblemen vorgestellt. Hierzu zählte eine Performance Analyse von Cinder über Ceph, als auch die Auswertung der HAProxy Log-Dateien, welche über Logmanagement Lösungen wie z.B. Splunk auch permanent ausgewertet werden können.


OpenStack Storage Across Datacenters

Für den Betrieb von einem Storage über mehrere Rechenzentren gibt es bei den OpenStack Komponenten gewisse Schwächen. Open vStorage bietet in Kombination mit einem Cinder Plugin eine Möglichkeit an, Object Storage in Blockstorage umzuwandeln und Cinder um eine entsprechende Skalierung zu erweitern. Ein Vorteil hierbei ist, dass bei einem Ausfall von Komponenten im gleichen Rechenzentrum über den Object-Storage die Daten weiterhin zur Verfügung gestellt werden.


Rackspace - "IS IT SAFE?" Taking Torture Out of OpenStack and Neutron

Bei dem Vortrag von Rackspace wurde auf die Vorstellung der Rackspace-Umgebung und den Rackspace Methoden zum deployen OpenStack von OpenStack eingegangen. Weiterhin wurde auch kurz die Zusammenarbeit mit und von Open-Xchange vorgestellt. Nach dieser Vorstellung wurden Methoden vorgestellt "Neutron ohne Schmerzen" mit dem Aufbau von OpenStack zu realisieren. Bei mittlerweile einer Anzahl von 60 Treibern und somit etwa 30000 Kombinationen ebendieser sollte man im Vorfeld genau betrachten, welche Möglichkeiten man in seiner OpenStack Umgebung tatsächlich nutzen möchte. Eine Lösungssuche in diesem Bereich wird bei dieser riesen Anzahl an Kombinationen von Netzwerkintegrationen sehr stark erschwert. Ein weiterer Punkt einer OpenStack Neutron Lösung gibt der Satz "Don't use new school tools with old school mind" wieder. Hierbei sollte darauf geachtet werden, dass die Methoden von OpenStack so genutzt werden wie sie vorgesehen sind. Ein Beispiel wurde hier mit der Vergabe von Floating-IPs vorgestellt. Die Vergabe nur einer Floating-IP Adresse für ein gesamtes Projekt ermöglicht so einen schnellen Neuaufbau oder Anpassung eines so definierten Projektes.


The OpenStack Innovation Center (OSIC) - Rackspace

Am Ende der Präsentation "Rackspace - "IS IT SAFE?" Taking Torture Out of OpenStack and Neutron" und fast nebenher wurde noch das Projekt OSIC vorgestellt. The OpenStack Innovation Center (OSIC) ermöglicht es Entwicklern bei Neuentwicklungen und Erweiterungen ihre Projekte auf Skalierung zu testen zu lassen, indem es den Entwicklern große OpenStack-Umgebungen zur Verfügung stellt.


Rule Breaker! - Upgrading an OpenStack Cloud While Skipping a Release

SUSE hat eine selbstentwickelte Methode vorgestellt, mit welcher Sie ein Upgrade von OpenStack auf die aktuellste Version durchführen können indem Sie ein offizielles Release überspringen. Dieses Upgrade wird über einen Wizard durchgeführt, indem der Administrator durch minimale Aktivitäten der alten und neuen Umgebungen das Upgrade durchführen kann. Auch bestimmte individuelle Anpassungen werden hierbei berücksichtigt. Der Wizard erstellt u.a. auch ein Backup der aktuellen Umgebung. In Zukunft plant SUSE ein auch nahtloses Upgrade der Umgebungen, welches über den entwickelten Mechanismus durchaus realistisch erscheint.

Dienstag, 3. November 2015

Neuigkeiten zur OpenStack Summit Tokyo

OpenStack Neuigkeiten von der OpenStack Summit
Um meinen Blog wieder etwas mit Leben zu befüllen habe ich mich entschlossen eine Zusammenfassung aller Neuigkeiten rum um das Thema OpenStack Summit Tokyo zu erstellen, in der Hoffnung sie hilft dem einen oder anderen weiter :-)

Trennung in Kern- und Optionale Dienste
OpenStack ist aufgrund seiner großen Anzahl an integrierten Projekten in den letzten Jahren sehr stark angewachsen. Die Anzahl der Komponenten führten im letzten Release Kilo zu einer gewissen Unübersichtlichkeit. Um dem entgegenzuwirken wurde im Rahmen der Veröffentlichung des Project Navigators eine offizielle Trennung zwischen den Core Komponenten und den zusätzlich zur Verfügung stehenden Addons eingeführt. Ein sinnvoller und längst überfälliger Schritt, da OpenStack schon seit mehreren Releases nur aus sechs Kernkomponenten besteht. Hiermit fällt es wesentlich leichter Neueinsteigern die Thematik näherzubringen. Zusätzlich dazu bietet der Projekt Navigator auch eine sehr gute Übersicht über den Aktuellen Stand der einzelnen Projekte.

Weitere Infos: 
http://www.openstack.org/software/project-navigator

Zertifizierungsprogramm von OpenStack
Um eine Konsolidierung beim Thema Zertifizierung im OpenStack Bereich zu erreichen führt die OpenStack Foundation mit Unterstützung einer großen Anzahl von Trainingspartnern (SUSE, HP, Mirantis) ein eigenes Zertifizierungsprogramm ein. Dieses Programm ist für Admins und Betreiber von OpenStack Umgebungen gedacht. Zielsetzung von OpenStack ist eine hohe Qualitätssicherung der Schulungen und Trainings sowie herstellerunabhängige Trainings zur Verfügung zu stellen. Die Einführung des Certified OpenStack Administrator ist aktuell im Q2/2016 geplant.

Weitere Infos:
http://www.openstack.org/coa
http://bit.ly/1LN3rSj

3 Mythen über OpenStack

Mirantis stellt aktuell eine gute Übersichts-Serie über die Top 3 Mythen im OpenStack Bereich zusammen. Die erste veröffentlichung vom 29. Oktober behandelt das Thema "Alle Distributionen sind gleich". Hier wird unter anderem auf die Themen Lifecycle Management, die beinhalteten Projekte, die Paketierung der Middlware und die Referenz Architekturen eingegangen.

Weitere Infos:
http://bit.ly/1MdqWVZ

Veröffentlichung Liberty (Version 12)

Mitte Oktober wurde wie traditionell kurz vor der OpenStack Summit in Tokyo eine OpenStack Version veröffentlicht. Mit Liberty nimmt die Anzahl der neu hinzugefügten Projekte langsam ab, dafür steht aktuell die Weiterentwicklung und die Optimierung aller vorhandenen Dienste im Fokus der Entwicklung. Für eine bessere Übersicht eine kurze Zusammenfassung der wichtigsten Änderungen in der Liberty Version 12:
  • Hochverfügbarkeit APIs für Nova wurden erweitert
  • Einführung von QoS der Netzwerke
  • Load Balancing as a Service wurde erweitert
    • Unter anderem für NFV (Network Functions Vritualization)
    •  Module können für F5-Load-Balancer konfigurieren
    •  Ein eigener Software Load-Balancer wurde vorgestellt (Octavia)
  • Orchestrierung (Heat) Performance und Robustheit wurde optimiert
  • DNS as a Service (Designate) wird eingeführt
  • Zentraler Speicher für Passwörter und Zertifikate (Barbican)
  • Telemetrie und Billing Service Ceilometer erhält eine eigene Datenbank (Gnocchi)
  • Versionsnummerierung aller Komponenten wurde angepasst

Weitere Infos: 
https://www.openstack.org/software/liberty/


Aktuelle Übersicht der OpenStack Distributionen

Die Zeiträume zur Veröffentlichung neuer OpenStack Enterprise Distributionen werden in den letzten Monaten immer länger, da nicht mehr so viele neue Features in die halbjährlichen Veröffentlichungen von OpenStack direkt hinzugefügt werden. Dies hat den Vorteil, dass die Lösungen langsam auch im produktiven Bereich eingesetzt werden können. Im Anhang eine kurze Übersicht über die aktuelle Benennung und Versionierung der in Deutschland vertretenden OpenStack Distributionen:

SUSE OpenStack Cloud 6 (Beta)- Liberty (http://bit.ly/1KDIIfK)
RHEL OpenStack 7 - Kilo (http://red.ht/1l4ZZK4)
Mirantis OpenStack 7.0 - Kilo (http://bit.ly/1Q6Reed)
HP Helion OpenStack 2.0 - Kilo (http://bit.ly/1XKBlfF)

Dienstag, 28. Januar 2014

Performance Probleme beim Booten mit resume

Performance Probleme beim Booten mit resume

Nach einem Umzug auf eine neue SSD ist mir aufgefallen, dass meine Boot-Zeit von Ubuntu 12.04 um etwa 5 Sekunden länger gedauert hat als sonst. Daraufhin begab ich mich auf die Suche nach dem Problem. Die Syslog Datei brachte nur einen kleinen Hinweis zu Tage, dem ich vorerst durch googlen versucht habe nachzugehen. Das Ergebnis war aber nicht zufriedenstellend, da mir nur Informationen mitgeteilt wurden, dass das Root-System unsauber gemountet wurde. Auch nach einem sauberen umount trat das Problem allerdings auf.

In der Zeitausgabe vom Kernel als Log in der Syslog Datei erschien ein Timeout von etwa 5 Sekunden.

Jan 28 22:53:41 desktop kernel: [    4.530862] usb 1-3.4.3: New USB device found, idVendor=0a12, idProduct=0001
Jan 28 22:53:41 desktop kernel: [    4.530868] usb 1-3.4.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jan 28 22:53:41 desktop kernel: [    8.783308] EXT4-fs (sda2): INFO: recovery required on readonly filesystem
Jan 28 22:53:41 desktop kernel: [    8.783310] EXT4-fs (sda2): write access will be enabled during recovery
Jan 28 22:53:41 desktop kernel: [    8.943384] EXT4-fs (sda2): recovery complete
Jan 28 22:53:41 desktop kernel: [    8.952596] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Jan 28 22:53:41 desktop kernel: [    9.414274] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro,user_xattr,discard
Jan 28 22:53:41 desktop kernel: [   10.845742] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: errors=remount-ro,discard

Jan 28 22:53:41 desktop kernel: [   10.855497] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

In den Logs tauchten folgende Infos nicht auf, welche ich aber auf dem Boot-Screen gesehen habe, nachdem ich die quiet und splash Parameter aus der /etc/default/grub Konfigurationsdatei entfernt habe.

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.

Danach habe ich die initrd auf dem System entpackt und bin den Boot-Prozess Step-by-Step durchgegangen.

[Desktop /]# mkdir /tmp/initrd↵
[Desktop /]# cd /tmp/initrd↵
[Desktop /tmp/initrd]# cp /boot/initrd.img-3.8.0-35-generic /tmp/initrd/initrd.gz↵
[Desktop /tmp/initrd]# gunzip initrd.gz
[Desktop /tmp/initrd]# cat initrd | cpio -id
[Desktop /tmp/initrd]# less init


Dabei ist bin ich auf das Script scripts/local-premount/resume gestossen, welches versucht hat das System von einer Swap-Partition herzustellen die nicht mehr existiert hat.

Den entsprechenden Parameter habe ich auf dem Desktop-System in der Datei /etc/initramfs-tools/conf.d/resume gefunden und komplett entfernt. Die Initrd habe ich danach mit dem Befehl:
[Desktop /root]# update-initramfs -u
neu erstellt. Danach bootete das System die vorhin genannten 5 Sec schneller.


Legende

Benutzer Root
[<Servername> <Pfad>]# <Befehl> <Dateiname>↵
Ausgabe

Benutzer
[<user>@<Servername>]$ <Befehl> <Dateiname>↵
Ausgabe

Tastenkombinationen:
Strg+a

Einzelne Tasten:


a

Dienstag, 18. Juni 2013

SLES 11 SP2 SMT Server - Howto

SLES 11 SP2 SMT Server - Howto

Einleitung

Der SMT Server ist eine freie Software zur einfachen Systemverwaltung von SUSE Linux Enterprise Servern (SLES10, SLES11). Er dient primär zur lokalen Verwaltung von den von SUSE zur Verfügung gestellten Reposiories um Netzwerktraffic zu sparen und einen besseren Überblick über seine Systemlandschaft zu gelangen. Neben den von SUSE zur Verfügung gestellten Repositorys können aber auch noch eigene hinzugefügt werden. 
Ein weiterer Vorteil des SMT ist die Möglichkeit ein Stageing von z.B. Test und Produktivumgebungen in der eigenen Serverlandschaft darzustellen. 
Neben diesen Funktionen bietet er auch die Möglichkeit Scripte zentral vom SMT aus auf den Clients auszuführen.

In diesem Howto beschreibe ich, wie ich den SMT nutze und wie am Ende die Ausgaben auszusehen haben. Bei der Installation verweise ich dabei auf die recht gute und ausgearbeitet SUSE Dokumentation.

Voraussetzung

NCC Zugang (Novell Customer Center)

Mindestens 3 Aktive Subscriptions für SLES 11 SP2

Einen Server

Name: server-smt
Betriebssystem: SLES 11
Netzwerkadapter:
eth0: 192.168.1.200
LVM Volume:
/dev/VolGroup00/smt 80 GB -> /var/lib/smt

Pakete:
SLES: smt

Anzahl Clients

Name: client1
Betriebssystem: SLES 11
Netzwerkadapter: eth0: 192.168.1.201

Name: client2
Betriebssystem: SLES 11
Netzwerkadapter: eth0: 192.168.1.202


Installation/Konfiguration

Das Subscription Management Tool steht frei zur Verfügung und kann bei SUSE https://download.suse.com/index.jsp in der Suche unter dem gleichnamigen Begriff runtergeladen werden. Die Installation läuft unter einer normal installierten SLES Instanz.

Unter der SLES Installation kann das runtergeladene Addon in YaST2 unter dem Punkt "Software" - "Add-On Product" hinzugefügt werden. Hierbei wird als Installationquelle die CD ausgewählt und die Installation nach Bestätigung der Lizenzvereinbarungen gestartet.

Eine ausführliche Installationsanleitung gibt es von SUSE unter dem folgenden Link:
Bei der Konfiguration ist drauf zu achten, dass der Domainname incl. Domain (FQND)  im ganzen Netzwerk erreichbar ist, da es sonst zu Problemen mit den vom SMT erstellten SSL Zertifikaten kommt.

Sobald die Server Konfiguration durchgeführt wurde geht es daran die Clients an das System anzubinden. Mit der folgenden Befehlsreihenfolge bin ich bisher immer gut gefahren:


Kopieren des Scripts clientSetup4SMT.sh auf die Clients:
[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client01: 
[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client02: ↵

Löschen der vorhandenen Repositories, dies verhindert, dass der Server noch auf die lokal Konfigurierten CD/DVSs zugreift, die häufig nicht mehr eingebunden sind:
[root@<client1> ~]# rm -rf /etc/zypp/repos.d/* ↵

Konfiguration des Clients:
[root@<client1> ~]# ./clientSetup4SMT.sh https://server-smt.bludau.home/center/regsvc ↵

Sollten eigene nicht zertifizierte Repositories mit eingebunden werden helfen noch folgende Befehle weiter, welche noch einmal nachfragen, ob nicht zertifizierte Pakete zugelassen werden.
[root@<client1> ~]# suse_register --restore-repos
[root@<client1> ~]# zypper ref

Anwendung

Im folgenden Absatz werden die wichtigen Befehle gelistet um den SMT Server zu benutzen.

Eine Liste aller angebundenen Clients und deren aktuellen Status gibt der Befehl smt-client aus. Der Status sollte möglichst auf Up-to-date sein, dies ist aber nicht immer realsierbar.


[root@server-smt ~]# smt-client ↵
.-----------------------------------------------------------------------------------------------.
| GUID                             | Hostname              | Patch Status | Patch Status Date   |
+----------------------------------+-----------------------+--------------+---------------------+
| 12345678901234567890123456789012 | client1               | Up-to-date      | 2013-06-17 12:17:31 |

12345678901234567890123456789013 | client2               | Critical     | 2013-06-17 12:15:07 |
'----------------------------------+-----------------------+--------------+---------------------'
[root@server-smt ~]#

Der SMT Server bietet die Möglichkeit einen Report zu generieren, in dem dargestellt wird, wie viele Subscription man aktuell hat und wie lange diese noch gültig sind.
[root@server-smt ~]# smt-report

Um den SMT Mirror auf den aktuellen Stand zu bringen reicht es aus den folgenden Befehl auszuführen. Sollen die Updates ständig eingespielt werden, kann dieser Befehl auch als Cronjob gestartet werden.
[root@server-smt ~]# smt-mirror


Sonntag, 16. Juni 2013

iscsi Basis - Howto

iscsi Basis - Howto

Einleitung

In diesem Howto beschreibe ich den Grundaufbau einer minimalen iscsi Umgebung. Hierbei handelt es sich um den Aufbau eines iscsi Servers und die Anbindung von einem Client an den zur Verfügung gestellten Pfad.

Vorraussetzungen

Einen Server

Name: server

Zwei Netzwerkadapter
eth0: 192.168.1.200
eth1: 192.168.201.200

LVM Volume:
/dev/VolGroup00/iscsi 1 GB

Pakete:
RedHat: scsi-target-utils

Zwei Clients

Name: client1

Zwei Netzwerkadapter
eth0: 192.168.1.201
eth1: 192.168.201.201

Pakete:
RedHat: iscsi-initiator-utils.x86, sg3_utils-1.28-4.el6.x86_64, lsscsi-0.23-2.el6.x86_64

Howto

Konfiguration Server

Auf dem Server wird nach der Installation der benötigen Pakete die Konfigurationsdatei target.conf angepasst. In Ihr werden als target Name ein eindeutiger iqn (iSCSI Qualified Name) benötigt. dieser befindet sich in dem <target> Tag. 
Der zur Verfügung stehenden Speicherplatz wird mit dem Parameter backing-store festgelegt. Hier bietet es sich an ein freies Blockdevice zu nehmen. Im Fall des Howtos ein frisch angelegtes LVM Device.
Mit dem Parameter initiator-address werden die definierten IP Adressen freigegeben und der Parameter scsi_sn legt die SCSI Seriennummer fest, welche später über udev ausgelesen werden kann.

[server ~]# cat /etc/tgt/targets.conf ↵
default-driver iscsi
# Target ist ein eindeutiger Name
<target iqn.2013-06-01.home.bludau:iscsi>

  backing-store /dev/VolGroup00/iscsi # LUN1

  initiator-address 192.168.1.200     # server
  initiator-address 192.168.201.201     # client1
  scsi_sn iscsi-seriennummer # SCSI Seriennummer

</target>
[server ~]#

Nach dieser Konfiguration muss der Dienst tgtd gestartet und als Service eingetragen werden.

[server ~]# service tgtd start 
[server ~]# chkconfig tgtd on 

Nach dieser Konfiguration kann mit dem folgenden Befehl überprüft werden, ob auch alle Konfigurationen wie gewünscht übernommen wurden.


[server ~]# tgt-admin -s 
Target 1: iqn.2013-06-01.home.bludau:iscsi
 ...
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: iscsi-seriennummer
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/VolGroup00/iscsi
            Backing store flags: 
    Account information:
    ACL information:
        192.168.1.200
        192.168.201.201
[server ~]# 

Hinter dem Target-Namen ist die iqn gelistet unter welcher das iscsi Device zur Verfügung steht. Backing Store gibt den auf dem Server genutzten Pfad aus und die ACL Informationen geben die IP Adressen zurück, für welche die iSCSI Targets freigegeben sind.

Konfiguration Clients

Um einen Client anzubinden ist die Konfiguration vom iscsi Daemon notwendig. Dieser kann mit folgenden Befehlen automatisch gestartet werden:
[client1 ~]# chkconfig iscsid on 
[client1 ~]# service iscsid start 

Danach ist die Anbindung vom Client an das iscsi Target vom Server notwendig. Um sich alle Freigaben anzeigen zu lassen hilft das Programm iscsiadm weiter, welches mit den Parametern "-m discovery -t sendtargets -p 192.168.201.200" vom Server her alle Targets gelistet bekommt.

Diese Freigabe wird dann genutzt um das Target an das System zu binden.

Anbinden des iscsi Targets bei dem Client client1:

[client1 ~]# lsscsi ↵
...
[client1 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.201.200 ↵
192.168.201.200:3260,1 iqn.2013-06-01.home.bludau:iscsi
[client1 ~]# iscsiadm -m node -T iqn.2013-06.home.bludau:iscsi -p 192.168.201.200 --login ↵
[client1 ~]# lsscsi ↵
...
[6:0:0:0]    storage IET      Controller       0001  -       
[6:0:0:1]    disk    IET      VIRTUAL-DISK     0001  /dev/sda 
...
[client1 ~]#

Ausgabe aller Informationen die unter UDEV ausgelesen werden können, dazu gehören unter anderem auch die Seriennummer:
[client1 ~]# udevadm info -q all -n /dev/sda ↵
...

Das ganze funktioniert auch um das Device wieder zu entfernen. Hierbei ist bei dem zweiten Commando aber darauf zu achten, dass anstelle des login Parameters logout angegeben wird. Zusäztlich sollte man vorher unbedingt darauf achten, dass die darauf erstellen Filesysteme ausgehängt wurden.

Entfernen von des iscsi Device von dem Client client1:

[client1 ~]# lsscsi ↵
...
[6:0:0:0]    storage IET      Controller       0001  -       
[6:0:0:1]    disk    IET      VIRTUAL-DISK     0001  /dev/sda 
...
[client1 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.201.200 ↵
192.168.201.200:3260,1 iqn.2013-06-01.home.bludau:iscsi
[client1 ~]# iscsiadm -m node -T iqn.2013-06.home.bludau:iscsi -p 192.168.201.200 --logout ↵
[client1 ~]# lsscsi ↵

Legende

Benutzer Root
[<Servername> <Pfad>]# <Befehl> <Dateiname> ↵
Ausgabe

Benutzer
[<user>@<Servername>]$ <Befehl> <Dateiname> ↵
Ausgabe

Tastenkombinationen:
Strg+a

Einzelne Tasten:
a

Samstag, 4. Mai 2013

Datenrettung von CD/DVDs mithilfe von PhotoRec/TestDisk

In meinem Blogeintrag "Datenrettung bei I/O Fehlern mit ddrescue" habe ich bereits geschrieben wie man Daten von einer Festplatte sichern kann.

Heute habe ich eine CD bekommen, welche mit I/O Fehlermeldungen Meldungen unter Linux und Windows ausgestiegen ist. Leider konnte ich sie nicht mal öffnen, da mir mitgeteilt wurde, dass das Filesystem beschädigt war.

Da ich wusste, das die Daten (Bilder) auf der CD vorhanden sind, habe ich nach einer Lösung gesucht um diese wieder herzustellen.

Über ein ddrescure habe ich den Großteil der CD auf meiner Platte gespeichert. (dd if=/dev/sr0 of=/home/thomas/sr0.img) und dann versucht darüber zu mounten. 


mount: wrong fs type, bad option, bad superblock on /dev/sr0,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

Leider hat dieser Versuch auch mit der gleichen Fehlermeldung geendet wie bei dem Versuch die CD direkt einzubinden.

Über einige Suche nach UDF Restore bin ich dann über den Befehl photorec gestossen, welcher ein Teil des Ubuntu-Packges testdisk ist.

Über eine menügesteuerte Übersicht konnte ich einen Großteil der Daten von meinem zuvor erstellten dd Image sichern.

Die Optionszeile lautet wie folgt:
photorec [/log] [/debug] [/d recup_dir] [device|image.dd|image.e01]

Durch die Eingabe des folgenden Befehls konnte ich meine Daten über das Menü wieder herstellen. Die Bilder befanden sich danach in dem Verzeichnis daten.1 :

# photorec /d daten sr0.img

In den folgenden Bildern werden die von mir durchgeführten Schritte noch im Programm grafisch dargestellt:


Als Auswahl des Filesystem hat es hier völlig ausgereicht Others auszuwählen.


Mittwoch, 27. Februar 2013

chgrp - Howto Grundlegende Systembefehle


Heute habe ich mich nach mehrmonatiger Abstinenz mal wieder die Zeit für einen neuen Eintrag in meinem Blog gefunden.

Weiter mache ich mit dem mehrteiligen Teil der "Grundlegenden Systembefehle". Durch die alphabetische Abarbeitung ist diesmal der Befehl chgrp an der Reihe.


chgrp

chgrp ändert die Gruppenberechtigungen für Dateien. Der Befehl setzt sich aus dem englischen "change group" zusammen.

Wichtig zur Benutzung:

Über den Befehl chgrp kann der Gruppenbesitzer einer Datei geändert werden. Dies ist im einfachsten Fall zur Änderung einer Datei oder Ordnerberechtigung wie folgt möglich:
chgrp <Gruppe> <Dateiname/Pfad>


Beispiel:
# chgrp users /home/thomas

Wir gehen hierbei davon aus, dass die Gruppe "users" eine Gruppe für alle Anwender ist und die Gruppe "meinegruppe" eine Gruppe nur für den Benutzer "thomas" ist. Gesetzt ist im Vorfeld die Gruppe "meinegruppe"

Das Ergebnis sieht nach dem Ausführen des Befehls oben wie folgt aus:
root@desktop:/home# ls -lah
...
drwxr-xr-x 63 thomas   users    16K Feb 26 22:59 thomas
root@desktop:/home# 

Um die Gruppberechtigung wieder nur dem ursprünglichen Benutzer zuzuweisen wird der Befehl wieder wie folgt ausgeführt:
# chgrp meinegruppe /home/thomas

Ergebnis:

root@desktop:/home# ls -lah
...
drwxr-xr-x 63 thomas   meinegruppe  16K Feb 26 22:59 thomas
root@desktop:/home#


Bisher haben wir nur dein Ordner ohne die Inhalte geändert. Um rekursive Änderungen über ganze Verzeichnisbäume durchzuführen hilft der Parameter -R weiter.

Achtung: Der folgende Befehl ändert die Gruppenzugehörigkeit aller Dateien und Unterordner im Verzeichnis /home/thomas auf den Gruppenbenutzer "users"
# chgrp -R users /home/thomas

Nice to Know

Die Parameter -v & -c zeigen beim Ausführen an, welche Dateien geändert wurden. Bei -v werden alle Dateien angezeigt, welche von chgrp benutzt werden. -c zeigt nur die Dateien an, welche auch wirklich geändert werden.

Besteht der Bedarf bei einer Rekursiven Änderung auch alle Ordner welche in dem Verzeichnis verlinkt sind zu verändern helfen der Parameter -L oder -H weiter. 

-L Ändert nur die Berechtigung für das Verzeichnis.
-H Ändert auch alle Dateien in dem unterliegendem Verzeichnis.


Hier ist allerdings Vorsicht angebracht, wenn man im Vorfeld nicht überprüft hat, wohin die Links führen. Standardmäßig werden die Dateien und Ordner hinter Links über den chgrp Befehl nicht mehr beachtet.



cat chgrp chmod chown cp date dd df dmesg echo false
hostname kill ln login ls mkdir mknod more mount mv ps
pwd rm rmdir sed sh stty su sync true umount uname

Weitere Informationen zum Thema grundlegende Systembefehle:

http://goo.gl/HxZ1N