[ansible@alarm ~]$ cat \/etc\/fstab \n# Static information about the filesystems.\n# See fstab(5) for details.\n\n# <file system> <dir> <type> <options> <dump> <pass>\n[ansible@alarm ~]$ sudo cat \/etc\/fstab\n# Static information about the filesystems.\n# See fstab(5) for details.\n\n# <file system> <dir> <type> <options> <dump> <pass>\n[ansible@alarm ~]$ <\/code><\/pre>\n\n\n\nOkay, kann man so machen.. seufz, damit h\u00e4lt man sich nat\u00fcrlich alle Freiheitsgrade offen, indem man die Medien gar nicht erst mountet.<\/p>\n\n\n\n
Bin ich pers\u00f6nlich jetzt keine Freund davon etwas ungemountet zu booten, aber ich kann es nachvollziehen, dass das Team es so gemacht hat. Dadurch k\u00f6nnen die drei verschiedenen Arten von Mount-Points nach dem ersten Booten bedient werden. (\/dev\/sdX versus Label versus UUID). Ich selber nutze sehr gerne zum Mounten die Label, weil meiner Meinung nach dadurch in einem sp\u00e4teren Update sich ver\u00e4ndernde Mount-Points a’la \/dev\/sda1 abgefangen werden und diese schwer handlebaren UUIDs umgangen werden k\u00f6nnen. Aber wie schon erw\u00e4hnt, was f\u00fcr mich war ist, mag noch lange nicht f\u00fcr jedes Szenario gelten.<\/p>\n\n\n\n
Na dann schau ich mir mal die Optionen zum Mounten im \/dev\/disk Baum genauer an.<\/p>\n\n\n\n
[ansible@alarm ~]$ sudo tree \/dev\/disk\/\n\/dev\/disk\/\n|-- by-id\n| |-- ata-SAMSUNG_HD203WI_S1UYJ1KZ100183 -> ..\/..\/sda\n| |-- ata-SAMSUNG_HD203WI_S1UYJ1KZ100183-part1 -> ..\/..\/sda1\n| |-- mmc-SC16G_0xb48f4515 -> ..\/..\/mmcblk0\n| |-- mmc-SC16G_0xb48f4515-part1 -> ..\/..\/mmcblk0p1\n| |-- wwn-0x50024e9002b89270 -> ..\/..\/sda\n| `-- wwn-0x50024e9002b89270-part1 -> ..\/..\/sda1\n|-- by-label\n| `-- ROOT -> ..\/..\/mmcblk0p1\n<snip>\n<\/code><\/pre>\n\n\n\nAm Ende steht mein gesetztes Label ROOT f\u00fcr die mmcblk0p1 Partition. Diese Partition m\u00f6chte ich jetzt auch gerne fest in der \/etc\/fstab stehen haben, damit nach sp\u00e4teren Software-Updates nichts ins Schlingern ger\u00e4t.<\/p>\n\n\n\n
Ich baue mir das Zielplaybook aus einzelnen kleinen Playbook-Configlets zusammen, deshalb pr\u00fcfe ich jetzt erstmal, ob das Mounten von einem \/ auf einem Node geht. Das Playbook-Configlets habe ich mir wie folgt ausgedacht.<\/p>\n\n\n\n
[ansible@barney ~]$ cat label_root_mount.yml \n---\n- name: All mount \/ by label ROOT\n hosts: glusterfs\n become: yes\n\n tasks:\n - name: generate LABEL=ROOT entry\n mount:\n path: \/\n src: LABEL=ROOT\n fstype: ext4\n opts: defaults,noatime\n state: present\n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nDamit ich das Playbook jetzt nicht gleich gegen alle Nodes lasse, habe ich mir die \/etc\/ansible\/host aufgeteilt, so da\u00df ich einzelne Nodes gezielt ansprechen kann. Die \/etc\/ansible\/host Textdatei sieht wie folgt aus.<\/p>\n\n\n\n
[root@barney ansible]# cat \/etc\/ansible\/hosts\n[glusterfs]\n192.168.2.143\n192.168.2.144\n192.168.2.145\n192.168.2.146\n192.168.2.25\n\n[g1]\n192.168.2.143\n\n[g2]\n192.168.2.144\n\n[g3]\n192.168.2.145\n\n[g4]\n192.168.2.146\n\n[g5]\n192.168.2.25\n[root@barney ansible]# <\/code><\/pre>\n\n\n\nIch vermute, in gr\u00f6\u00dferen Installationen wird wohl eher mit dem DNS Namen der Nodes hantiert als mit der IPv4 Adresse, ist mir jetzt aber erstmal Wurst..<\/p>\n\n\n\n
Okay, dann lassen wir mal das Playbook-Configlets gegen den Node g5 laufen und schauen uns an, wie das Ergebnis aussieht.<\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook label_root_mount.yml --limit g5\n\nPLAY [All mount \/ by label ROOT] ***************************************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.25]\n\nTASK [generate LABEL=ROOT entrie] **************************************************************************************************************************\nchanged: [192.168.2.25]\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0 \n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nSpannend war es jetzt f\u00fcr mich, da ich mir nicht ganz sicher war, was der Node denn nun wirklich als Ergebnis in der \/etc\/fstab stehen hat. Ich seh mal nach.<\/p>\n\n\n\n
[ansible@alarm ~]$ cat \/etc\/fstab \n# Static information about the filesystems.\n# See fstab(5) for details.\n\n# <file system> <dir> <type> <options> <dump> <pass>\nLABEL=ROOT \/ ext4 defaults,noatime 0 0\n[ansible@alarm ~]$ <\/code><\/pre>\n\n\n\nSieht gut aus, allerdings gibt es noch ein Delta zwischen \/etc\/fstab und gelebter \/etc\/mtab. Daf\u00fcr werde ich den Node jetzt mach rebooten und dann sollten die beiden symmetrisch sein.<\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook reboot.yml --limit g5\n\nPLAY [All hosts reboot] ************************************************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.25]\n\nTASK [Unconditionally reboot the machine with all defaults] ************************************************************************************************\nchanged: [192.168.2.25]\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0 \n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nNach dem kleinen Klaps sieht es jetzt so aus, wie ich es haben wollte. Die microSD Karte ist \u00fcber das Label gemountet.<\/p>\n\n\n\n
[ansible@alarm ~]$ lsblk -Tf\nNAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT\nsda \n`-sda1 xfs 03df1da5-89d0-4fd3-8bf4-69cbbe8d87ce \nmmcblk0 \n`-mmcblk0p1 ext4 ROOT 5ab9cbdc-0a5f-4fe8-8910-afdda9eafb81 12.4G 10% \/<\/code><\/pre>\n\n\n\nNun wird es Zeit, die verbaute HDD der Nodes f\u00fcr die Nutzung im GlusterFS einzurichten. Daf\u00fcr verwerfe ich das auf der HDD existierende Setup erst einmal weg.<\/p>\n\n\n\n
Ich hab jetzt eine gute Stunde gebraucht, um festzustellen, dass auf meinen Nodes alle Befehle vom Modul parted nicht ausgef\u00fchrt werden. Ich stell da mal eine steile Hypothese auf, das Modul parted braucht auf dem Nodes das Programm parted. Ich werde das also mal Installieren und gucken ob das Playbook dann sauber durch l\u00e4uft.<\/em><\/p>\n\n\n\nAlso schraub ich mir ein Playbook zum Ausrollen von parted.<\/p>\n\n\n\n
[ansible@barney ~]$ cat parted.yml\n---\n- name: All hosts install parted\n hosts: glusterfs\n become: yes\n \n tasks:\n - name: install parted\n pacman:\n name: parted\n update_cache: yes\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nUnd l\u00e4uft es durch?<\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook parted.yml --limit g5\n\nPLAY [All hosts install parted] ****************************************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.25]\n\nTASK [install parted] **************************************************************************************************************************************\nchanged: [192.168.2.25]\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0 \n[ansible@barney ~]$<\/code><\/pre>\n\n\n\nOkay, jetzt ist auf Node g5 also das Programm parted ausgerollt und jetzt lass ich nochmal das Playbook zum L\u00f6schen der Partition auf Node g5 los.<\/p>\n\n\n\n
---\n- name: All remove all partitions on sda\n hosts: glusterfs\n become: yes\n\n tasks:\n - parted:\n device: \/dev\/sda\n number: 1\n state: absent\n<\/code><\/pre>\n\n\n\nDiese Partition stammt aus meinen Versuchen mit unterschiedlichen Softgware Defined Storages (Ceph\/Hadoop\/GlusterFs). F\u00fcr mich stellt sich GlusterFS als am leichtesten handlebar dar, auch hier mag jeder zu seiner eigenen Sichtweisekommen auf Basis seines Bedarfs.<\/p>\n\n\n\n
Nun gut, was macht denn nun das Playbok zum L\u00f6schen der Partion #1 auf SDA?<\/p>\n\n\n\n
<\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook remove_all_partitions_on_hdd.yml --limit g5\n\nPLAY [All remove all partitions on sda] ********************************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.25]\n\nTASK [parted] **********************************************************************************************************************************************\nchanged: [192.168.2.25]\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0 \n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nJetzt noch flott eon pr\u00fcfender Blick direkt ins Filesystem des Node g5.<\/p>\n\n\n\n
[ansible@alarm ~]$ lsblk -Tf\nNAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT\nsda \nmmcblk0 \n`-mmcblk0p1 ext4 ROOT 5ab9cbdc-0a5f-4fe8-8910-afdda9eafb81 12.4G 10% \/\n[ansible@alarm ~]$ \n<\/code><\/pre>\n\n\n\nEs hat funktioniert, die Partition sda1 ist gel\u00f6scht. Sicherlich geistern die Testdaten jetzt noch auf der HDD rum, aber was solls.<\/p>\n\n\n\n
Als n\u00e4chstes m\u00f6chte ich jetzt eine Partition auf \/dev\/sda anlegen mit den Label=BRICK. Das Filesystem dieser BRICK Partition muss XFS sein. Das Playbook daf\u00fcr habe ich mir wiefolgt vorgestellt.<\/p>\n\n\n\n
[ansible@barney ~]$ cat make_sda1_partition.yml \n---\n- name: All make one partition on sda1 with xfs\n hosts: glusterfs\n become: yes\n\n tasks:\n - name: Create sda1 partition\n parted:\n device: \/dev\/sda\n label: gpt\n number: 1\n state: present\n part_start: 0%\n part_end: 100%\n\n - name: Create a xfs filesystem on \/dev\/sda1\n filesystem:\n fstype: xfs\n dev: \/dev\/sda1\n opts: -i size=512\n\n - name: Label sda1 partition with LABEL=BRICK\n command: \"xfs_admin -L BRICK \/dev\/sda1\"\n become: true\n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nDer Knackpunkt in diesem Ablauf ist, dass ich es auf Biegen und Brechen nicht hinbekommen habe mit den standard Ansible Modulen ein Label f\u00fcr die neue Partition zu setzen. Deshalb steht da im Playbook so ein h\u00e4ssliches Bash Command drin, aber nun ja. Dann lass ich mal mein erstes Playbook mit drei Tasks ausrollen. Mal sehen, ob das so geht, wie ich es mir vorstelle.<\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook make_sda1_partition.yml --limit g5\n\nPLAY [All make one partition on sda1 with xfs] *************************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.25]\n\nTASK [Create sda1 partition] *******************************************************************************************************************************\nchanged: [192.168.2.25]\n\nTASK [Label sda1 partition with LABEL=BRICK] ***************************************************************************************************************\nchanged: [192.168.2.25]\n\nTASK [Create a xfs filesystem on \/dev\/sda1] ****************************************************************************************************************\nok: [192.168.2.25]\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.25 : ok=4 changed=2 unreachable=0 failed=0 \n\n[ansible@barney ~]$<\/code><\/pre>\n\n\n\nAusgerollt ist es jedenfalls. Bei Filesystemver\u00e4nderungen sehe ich lieber genau nach, bevor ich weiter mache.<\/p>\n\n\n\n
[ansible@alarm ~]$ ls -l \/dev\/disk\/by-label\/\ntotal 0\nlrwxrwxrwx 1 root root 10 Mar 31 15:52 BRICK -> ..\/..\/sda1\nlrwxrwxrwx 1 root root 15 Mar 31 09:56 ROOT -> ..\/..\/mmcblk0p1\n\n\n[ansible@alarm ~]$ lsblk -Tf\nNAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT\nsda \n`-sda1 xfs BRICK cdc27797-15eb-4e4d-b58e-3e6ad3315112 \nmmcblk0 \n`-mmcblk0p1 ext4 ROOT 5ab9cbdc-0a5f-4fe8-8910-afdda9eafb81 12.4G 10% \/\n\n[ansible@alarm ~]$ sudo xfs_db -c info \/dev\/sda1\nmeta-data=\/dev\/sda1 isize=512 agcount=4, agsize=122091705 blks\n = sectsz=512 attr=2, projid32bit=1\n = crc=1 finobt=1, sparse=1, rmapbt=0\n = reflink=0\ndata = bsize=4096 blocks=488366820, imaxpct=5\n = sunit=0 swidth=0 blks\nnaming =version 2 bsize=4096 ascii-ci=0, ftype=1\nlog =internal log bsize=4096 blocks=238460, version=2\n = sectsz=512 sunit=0 blks, lazy-count=1\nrealtime =none extsz=4096 blocks=0, rtextents=0\n\nansible@alarm ~]$ <\/code><\/pre>\n\n\n\nDas sieht doch nach einem g\u00fcltigen Versuch aus. Es gibt eine Partition \/dev\/sda1 mit dem Label BRICK. Die orginale Anleitung zum GlusterFS<\/a> sieht vor, dass die XFS Storage-Partitionen nach \/export\/sdX1 gemountet wird. Also lassen wir Ansible mal ein Verzeichnis \/export erzeugen, worin danach \/export\/sda1 erzeugt wird. das Playbook daf\u00fcr stelle ich mir wie folgt vor.<\/p>\n\n\n\n[ansible@barney ~]$ cat mkdir_export_mount_label_brick.yml \n---\n- name: Generate \/export\/sdb1 and mount into fstab\n hosts: glusterfs\n become: yes\n\n tasks:\n - name: Creates directory and subdirectory\n file:\n path: \/export\/sda1\n state: directory\n\n - name: generate LABEL=BRICK entry\n mount:\n path: \/export\/sda1\n src: LABEL=BRICK\n fstype: xfs\n opts: defaults\n state: present\n\n[ansible@barney ~]$ <\/code><\/pre>\n\n\n\nWenn ich mir das Ergebnis des Playbooks ansehe, bin ich zufrieden. Nach einem Reboot sollte dann die Partition sauber gemountet sein.<\/p>\n\n\n\n
[ansible@alarm ~]$ tree -dfugA \/export\/\n\/export\n\u2514\u2500\u2500 [root root ] \/export\/sda1\n\n1 directory\n\n[ansible@alarm ~]$ cat \/etc\/fstab \n# Static information about the filesystems.\n# See fstab(5) for details.\n\n# <file system> <dir> <type> <options> <dump> <pass>\nLABEL=ROOT \/ ext4 defaults,noatime 0 0\nLABEL=BRICK \/export\/sda1 xfs defaults 0 0\n\n[ansible@alarm ~]$ <\/code><\/pre>\n\n\n\nAlso steht als letzes f\u00fcr die Vorbereitung der GlusterFS installation noch ein Reboot an, daf\u00fcr nehme ich das oben bereits beschriebene Playbook reboot.yml nochmal zur Hand und lasse es auf Node g5 los und sehe mir nachdem Reboot das Ergebnis auf dem Node g5 an.<\/p>\n\n\n\n
[ansible@alarm ~]$ lsblk -Tf \nNAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT\nsda \n`-sda1 xfs BRICK cdc27797-15eb-4e4d-b58e-3e6ad3315112 1.8T 0% \/export\/sda1\nmmcblk0 \n`-mmcblk0p1 ext4 ROOT 5ab9cbdc-0a5f-4fe8-8910-afdda9eafb81 12.4G 10% \/\n\n[ansible@alarm ~]$ <\/code><\/pre>\n\n\n\nDas sieht genau so aus, wie ich es haben wollte. Damit sind die Vorbereitung des Dateisystems und der Partitonen abgeschlossen. Die einzelnen Code-Schnipsel baue ich jetzt noch in ein zusammenh\u00e4ngendes Playbook zusammen und lasse es dann \u00fcber das gesammte Setup laufen. <\/p>\n\n\n\n
Das finale Plabook lief fast zufriedenstellend durch. \ud83d\ude09 <\/p>\n\n\n\n
[ansible@barney ~]$ ansible-playbook preinstallation_glusterfs.yml\n\nPLAY [Vorbereiten der Nodes vor der GlusterFS installation] ************************************************************************************************\n\nTASK [Gathering Facts] *************************************************************************************************************************************\nok: [192.168.2.146]\nok: [192.168.2.144]\nok: [192.168.2.145]\nok: [192.168.2.143]\nok: [192.168.2.25]\nok: [192.168.2.137]\n\nTASK [Installiere parted] **********************************************************************************************************************************\nok: [192.168.2.25]\nchanged: [192.168.2.145]\nchanged: [192.168.2.144]\nchanged: [192.168.2.143]\nchanged: [192.168.2.146]\nok: [192.168.2.137]\n\nTASK [Installiere glusterfs] *******************************************************************************************************************************\nchanged: [192.168.2.25]\nchanged: [192.168.2.144]\nchanged: [192.168.2.145]\nchanged: [192.168.2.146]\nchanged: [192.168.2.143]\nok: [192.168.2.137]\n\nTASK [Erzeuge einen FSTAB Eintrag f\u00fcr LABEL=ROOT] **********************************************************************************************************\nchanged: [192.168.2.145]\nchanged: [192.168.2.143]\nchanged: [192.168.2.144]\nok: [192.168.2.25]\nchanged: [192.168.2.146]\nok: [192.168.2.137]\n\nTASK [L\u00f6sche existierende Partitionen SDA1 auf SDA] ********************************************************************************************************\nfatal: [192.168.2.25]: FAILED! => {\"changed\": false, \"err\": \"Warning: Partition \/dev\/sda1 is being used. Are you sure you want to continue?\\n\", \"msg\": \"Error while running parted script: \/usr\/bin\/parted -s -m -a optimal \/dev\/sda -- rm 1\", \"out\": \"\", \"rc\": 1}\nchanged: [192.168.2.143]\nchanged: [192.168.2.144]\nchanged: [192.168.2.146]\nchanged: [192.168.2.145]\nfatal: [192.168.2.137]: FAILED! => {\"changed\": false, \"err\": \"Warning: Partition \/dev\/sda1 is being used. Are you sure you want to continue?\\n\", \"msg\": \"Error while running parted script: \/usr\/bin\/parted -s -m -a optimal \/dev\/sda -- rm 1\", \"out\": \"\", \"rc\": 1}\n\nTASK [Erzeuge eine SDA1 Partition] *************************************************************************************************************************\nchanged: [192.168.2.143]\nchanged: [192.168.2.144]\nchanged: [192.168.2.145]\nchanged: [192.168.2.146]\n\nTASK [Formatiere SDA1 mit XFS] *****************************************************************************************************************************\nchanged: [192.168.2.143]\nchanged: [192.168.2.145]\nchanged: [192.168.2.144]\nchanged: [192.168.2.146]\n\nTASK [Umlabeln der SDA1 mit LABEL=BRICK] *******************************************************************************************************************\nchanged: [192.168.2.145]\nchanged: [192.168.2.146]\nchanged: [192.168.2.144]\nchanged: [192.168.2.143]\n\nTASK [Erzeuge Verzeichnis \/export\/sda1] ********************************************************************************************************************\nchanged: [192.168.2.143]\nchanged: [192.168.2.144]\nchanged: [192.168.2.146]\nchanged: [192.168.2.145]\n\nTASK [Erzeuge einen FSTAB Eintrag f\u00fcr LABEL=BRICK] *********************************************************************************************************\nchanged: [192.168.2.143]\nchanged: [192.168.2.144]\nchanged: [192.168.2.145]\nchanged: [192.168.2.146]\n\nTASK [Durchbooten um die FSTAB Eintr\u00e4ge zu aktivieren] *****************************************************************************************************\nchanged: [192.168.2.144]\nchanged: [192.168.2.146]\nchanged: [192.168.2.143]\nchanged: [192.168.2.145]\n to retry, use: --limit @\/home\/ansible\/preinstallation_glusterfs.retry\n\nPLAY RECAP *************************************************************************************************************************************************\n192.168.2.137 : ok=4 changed=0 unreachable=0 failed=1 \n192.168.2.143 : ok=11 changed=10 unreachable=0 failed=0 \n192.168.2.144 : ok=11 changed=10 unreachable=0 failed=0 \n192.168.2.145 : ok=11 changed=10 unreachable=0 failed=0 \n192.168.2.146 : ok=11 changed=10 unreachable=0 failed=0 \n192.168.2.25 : ok=4 changed=1 unreachable=0 failed=1 \n\n[ansible@barney ~]$ \n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"Nachdem Ansible nun auf die Nodes zugreifen kann, folgt der n\u00e4chste Schritt. Ich werde mich St\u00fcck f\u00fcr St\u00fcck an die notwendigen Bestandteile eines Playbooks an n\u00e4hern. Ziel ist es, ein Playbook zu erhalten, welches...<\/p>\n","protected":false},"author":2,"featured_media":1158,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[55,53,60],"class_list":["post-1161","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","tag-ansible","tag-linux-arch","tag-preinstallation"],"_links":{"self":[{"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1161","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1161"}],"version-history":[{"count":26,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1161\/revisions"}],"predecessor-version":[{"id":1192,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1161\/revisions\/1192"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=\/wp\/v2\/media\/1158"}],"wp:attachment":[{"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1161"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1161"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.fotoandnet.de\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1161"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}