OpenStack Berechtigungen

Mich hat es Nerven gekostet:
keystone role-list
keystone user-list
keystone tenant-list

Ein User (meist in der entsprechenden conf-Datei hinterlegt) muss auch als keystone user (also in der user-Tabelle in der Keystone-DB) eingetragen sein.
Desweiteren muss es einen Tenant (Container, Mieter,Projekt,???) geben, der Berechtigungen umschreibt (Vllt. sollte ich nochmal lesen, was das Dingen wirklich macht)
Und es muss noch dazu die passende Rolle geben…
am Ende macht ein
keystone user-role-add --user=USERNAME_AUS_CONF --role=ADMIN_ROLLEN_ID --tenant_id=SERVICE_ID
die Möglichkeit, dass ein Service / User sich mit Keystone verbindet…
Normalerweise sollte es daher reichen:
in der conf-Datei:
admin_tenant_id=admin
admin_user=nova
(Oder nen anderen Servicenamen)
Und dann
keystone user-role-add --user nova --role=admin --tenant service

OpenStack Installationsprobleme unter Debian

Die haben sich ja viel Mühe mit der Installationsanleitung für OpenStack unter Debian 7 gegeben. Aber irgendwie tut es bei mir doch nicht alles, was es tun sollte…
Scheinbar klappt die Initialisierung der DB mit den korrekten User und Tenant-Einstellungen automatisiert über dbconfig nicht richtig (bei mir jedenfalls nicht.)
Am Ende sind keine User in der keystonedb-Tabelle user eingetragen, das mus man dann doch wieder händisch machen…
Am besten erstmal in der /etc/keystone/keystone.conf ein eigenes Admin-Token hinterlegen (Sch* auf Sicherheit, ich nehm mal 123)
Dann den Dienst neustarten.
Dann etwa so:
export OS_SERVICE_TOKEN=123
export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0

und dann in etwa so:
keystone tenant-create --name=admin --description="Admin Tenant"
keystone tenant-create --name=service --description="Service Tenant"
keystone user-create --name=admin --pass=ADMIN_PASS --email=root@localhost
keystone role-create --name=admin
keystone user-role-add --user=admin --tenant=admin --role=admin

Und schon klappt es…

KVM-Networking 2 (mit mehreren NICs)

Wenn ich jetzt nicht alle VMs mit in meine eine Bridge packen will, muss man etwas anderes machen.
Für jede VM erstelle ich mir erstmal ne eigenen Bridge
brctl addbr br[2-x]
ip addr set dev brX 10.0.X.1
ip link set dev brX up

In der XML-Datei für die VM trage ich dann sowas ein

Wenn ich jetzt noch nen DHCP-Server für die Interfaces aufsetze (z.B. dhcpd von isc) und dort sowas eintrage
subnet 10.0.X.0 netmask 255.255.255.0 {
option routers 10.0.X.1;
range 10.0.X.10 10.0.X.200;
}

und in der
/etc/default/isc-dhcp-server
die Bridges eintrage, spielt der DHCP auch nicht im LAN verrückt, sondern versorgt nur die einzelnen VMs mit IPs.

Damit die Kommunikation nach draussen klappt, muss noch eine Route auf dem Host gesetzt werden, der das (hier genutzte) 10er Netz routet…

Netzwerkforensik – Toolsammlung

Weil es langsam viel wird … ich habe mal angefangen, meine Toolsammlung von NWF-SW zusammenzuführen.
Und weil ich keine Lust hatte, das alles wieder schön in MySQL, PHP oder WordPress-Tabellen zu tackern, hab ich einfach mal Excel genommen. Hat auch den charmanten Vorteil, dass ich das problemlos immer weiter führen kann.

Die Liste ist logischerweise nicht vollständig. Anders gesagt, da stehen erst ein paar drin, aber ich führe die Liste immer weiter.
Ausserdem ist das ja auch nur für mich, warum rechtfertige ich mich also?!?

Hier der Link zum Owncloud-Server: Klick