{"id":718,"date":"2015-10-01T02:54:36","date_gmt":"2015-10-01T00:54:36","guid":{"rendered":"http:\/\/hobbykeller.spdns.de\/?p=718"},"modified":"2016-06-09T00:39:53","modified_gmt":"2016-06-08T22:39:53","slug":"running-a-git-server-on-openwrt","status":"publish","type":"post","link":"https:\/\/hobbykeller.spdns.de\/?p=718","title":{"rendered":"Running a git server on OpenWRT"},"content":{"rendered":"<p>If you want do serious programming, you sooner or later need to work with a version control system such as Subversion, Mercrurial or &#8211; probably the best choice &#8211; git. As far as git is concerned, you have got 3 choiches: (1) run the version control system locally, (2) use some public service like github and (3) set up a server of your own. This post explains how to realize option (3) on an OpenWRT router.<!--more--><\/p>\n<h1>Reconciling OpenWRT&#8217;s single-user setup with git<\/h1>\n<p>Although there are ways to create additional users, OpenWRT is basically intended to be a single user system, i.e. there is root and that&#8217;s it. On the other hand, git relies on the operating system to set the correct access rights to the repositories, so oWRT&#8217;s single user philosophy is hard to reconcile with git&#8217;s requirements regarding acces rights. The good news is, there are basically 2 ways to overcome this contradiction:<\/p>\n<h2>git over http<\/h2>\n<p>My first idea was share git&#8217;s services with the outside world over http(s), which is said to be possible with more recent versions of git. There are 2 major advantages, if one could set up such a structure.<\/p>\n<ul>\n<li>If git services are transported by the http protocol, the access permissions can be set at the web server level and there is no need to create users on the OpenWRT system. The single-user obstacle would therefore be eliminated.<\/li>\n<li>There is no danger that users behind a corporate firewall or similar cannot connect to the git server, as port 80 is always open.<\/li>\n<\/ul>\n<p>Unfortunately, all my attempts to set up a git server with lighttpd failed and I was unable to figure out the underlying problem &#8211; most probably it failed because I had either a wrong file permissioning on the working directory or a flawed configuration of the server, or maybe both. That said, the disadvantage of providing git access over http is that the web server&#8217;s configuration file quickly becomes too overloaded.<\/p>\n<h2>git over ssh<\/h2>\n<p>The alternative is to connect to git the traditional way, which is over ssh protocol. Unfortunately, there is little granularity as far as permissioning is concerned &#8211; and with OpenWRT&#8217;s single-user philosophy, things get even worse. This is where <a href=\"http:\/\/gitolite.com\/gitolite\/index.html\" target=\"_blank\">gitolite<\/a> comes into the game. There is even <a href=\"http:\/\/wiki.openwrt.org\/doc\/howto\/gitolite\" target=\"_blank\">a how to on the OpenWRT<\/a> website on how to set up gitolite, although it is a bit outdated. But with a few additional tweaks, you get a git service which runs really smooth.<\/p>\n<h1>Installation prerequisites<\/h1>\n<h2>extroot and dedicated partition<\/h2>\n<p>This post assumes that you are running your OpenWRT device with a <a href=\"http:\/\/wiki.openwrt.org\/doc\/howto\/extroot.old\" target=\"_blank\">pivot-overlay<\/a>. As repositories are usually hungry for disk storage and embedded devices only have limited capacity, it makes sense to add some USB-storage.<\/p>\n<p>Additionally, it makes sense to have the storage in a dedicated partition in order to separate it from the storage of the remaining operating system (afaik, there is no way to set user quotas in git\/gitolite). I set apart a 2 GB partition, which I formatted as ext4.<\/p>\n<p>As gitolite is completely installed in the \/root directory on the oWRT device, your fstab entry should look like this (assuming that the 2GB partition you set apart for git is the 2nd partition on the external storage device):<\/p>\n<pre class=\"lang:default decode:true\">config 'mount'                     \r\n    option  target  '\/root'\r\n    option  device  '\/dev\/sda2'    \r\n    option  fstype  'ext4' \r\n    option  options 'rw,sync'\r\n    option  enabled '1'        \r\n    option  enabled_fsck '1'\r\n<\/pre>\n<h2>Perl Language<\/h2>\n<p>As gitolite is written in Perl, you need to install a perl base system and a couple of modules. This is one point, where the instructions on the OpenWRT site look a bit outdated, as they ask you to install modules such as <code>perlbase-hostname<\/code> although these modules are officially deprecated in Perl and no longer offered as an OpenWRT package.<\/p>\n<p>Below is a list of the current Perl modules needed to run gitolite. Install those by <code>opkg install<\/code> or &#8211; better still &#8211; directly activating them in the <code>make menuconfig<\/code> prior to compiling your oWRT system binaries.<\/p>\n<pre class=\"lang:default decode:true\" title=\"Per modules needed for gitolite\">perl - 5.20.0-6\r\nperlbase-base - 5.20.0-6\r\nperlbase-bytes - 5.20.0-6\r\nperlbase-config - 5.20.0-6\r\nperlbase-cwd - 5.20.0-6\r\nperlbase-data - 5.20.0-6\r\nperlbase-errno - 5.20.0-6\r\nperlbase-essential - 5.20.0-6\r\nperlbase-fcntl - 5.20.0-6\r\nperlbase-file - 5.20.0-6\r\nperlbase-findbin - 5.20.0-6\r\nperlbase-getopt - 5.20.0-6\r\nperlbase-io - 5.20.0-6\r\nperlbase-list - 5.20.0-6\r\nperlbase-scalar - 5.20.0-6\r\nperlbase-selectsaver - 5.20.0-6\r\nperlbase-symbol - 5.20.0-6\r\nperlbase-sys - 5.20.0-6\r\nperlbase-tie - 5.20.0-6\r\nperlbase-xsloader - 5.20.0-6<\/pre>\n<p>The opkg installation command is as follows:<\/p>\n<pre class=\"wrap:true wrap-toggle:false lang:default decode:true \" title=\"opkg installation of perl\">opkg install perl perlbase-base perlbase-bytes perlbase-config perlbase-cwd perlbase-data perlbase-errno perlbase-essential perlbase-fcntl perlbase-file perlbase-findbin perlbase-getopt perlbase-io perlbase-list perlbase-scalar perlbase-selectsaver perlbase-symbol perlbase-sys perlbase-tie perlbase-xsloader\r\n<\/pre>\n<h2>git Preparations<\/h2>\n<p>Before installing gitolite, git must be installed on your system. Install it by issuing <code>opkg install git<\/code> or &#8211; better still &#8211; by directly selecting the git package when doing <code>make menuconfig<\/code> prior to your installation.<\/p>\n<p>Apart from that &#8211; and that is one point missing in the OpenWRT docs on how to install gitolite &#8211; gitolite expects to retrieve the git user name and email address of the git admin on the router. If these attributes are not set, gitolite will issue a warning in the installation. So it is better to configure git before the gitolite installation:<\/p>\n<pre class=\"lang:default decode:true\" title=\"Configuring git\">root@OpenWRT: git config --global user.name \"Git Admin\"\r\nroot@OpenWRT: git config --global user.email account@mailprovider.com<\/pre>\n<h2>Your ssh key for gitolite access<\/h2>\n<p>Although this step is only thinly documented in the oWRT howto, it is <strong>one of the most crucial steps<\/strong> which took quite a while for me to figure out. Basically, you need a public ssh key which will then be appended to the <code>\/etc\/dropbear\/authorized_keys<\/code> file on your oWRT machine. It is on the basis of that key that an external git user will be granted access to the machine. The problem with using such an ssh key is twofold:<\/p>\n<ul>\n<li>On the OpenWRT server, you do not want git users to get root access to your machine &#8211; but this would be exactly what would happen if the key was simply added to the <code>authorized_keys<\/code> file. gitolite solves that problem by adding a special preamble to the key which forces the user to a special gitolite-shell with restricted access.<\/li>\n<li>Given the fact that users presenting the gitolite key are forced into a restricted environment on the OpenWRT machine, it is impossible to use an existing key which already grants unrestricted ssh root access as a key for git(olite) access at the same time. While this should not be any problem for external users whose keys are not already in the OpenWRT <code>authorized_keys<\/code> file, the oWRT server admin &#8211; who normally also wants gitolite access for adminstering the git server &#8211; cannot use his existing ssh key for gitolite.<\/li>\n<\/ul>\n<h3>In case you are both adminstrator and (future) git user<\/h3>\n<p>In case you are both the adminsitrator of the oWRT machine (who already has put his key in the <code>\/etc\/dropbear\/authorized_keys<\/code> file on the oWRT server) and a git user, generate another key with <code>ssh-keygen<\/code> and <strong>make sure it has a name other than <code>id_rsa<\/code> <\/strong>when prompted where to save the key. <strong>Do not use the default setting<\/strong> or you risk that your existing key pair is overwritten and you lose access to any server which you access by your ssh key (for instance your oWRT machine).<\/p>\n<pre class=\"lang:default decode:true\" title=\"Generating an ssh key for git\">ilek@i7:~$ ssh-keygen -t rsa -b 2048 -C \"gitadmin@clientMachine\"\r\nGenerating public\/private rsa key pair.\r\n##### THINK TWICE   B E F O R E   YOU HIT ENTER AT THE FOLLOWING PROMPT #####\r\nEnter file in which to save the key (\/home\/ilek\/.ssh\/id_rsa): \/home\/ilek\/.ssh\/id_rsa_git\r\nEnter passphrase (empty for no passphrase): \r\nEnter same passphrase again: \r\nYour identification has been saved in \/home\/ilek\/.ssh\/id_rsa_git.\r\nYour public key has been saved in \/home\/ilek\/.ssh\/id_rsa_git.pub.\r\n<\/pre>\n<p>Now that you have a second pair of ssh keys which will later serve as your git key, you must find a way to tell ssh when to use which key. The easiest way to do that is by creating a <code>config<\/code> file. If you have your standard key pair <code>id_rsa<\/code> (which I will refer to as the &#8220;default&#8221; key and <code>id_rsa_git<\/code> (which I will refer to as the &#8220;git&#8221; key), just put a config file in your <code>~\/.ssh<\/code> directory which looks like this:<\/p>\n<pre class=\"lang:default decode:true\" title=\"ssh config file to select keys\">Host git\r\n    user            root\r\n    hostname        &lt;IP or URI of OpenWRT Machine&gt;\r\n    port            22\r\n    identityfile    ~\/.ssh\/id_rsa_git.pub\r\n\r\nHost main\r\n    user            root\r\n    hostname        &lt;IP or URI of OpenWRT Machine&gt;\r\n    port            22\r\n    identityfile    ~\/.ssh\/id_rsa.pub\r\n<\/pre>\n<p>Note that both users log in as root. Gitolite&#8217;s trick is to identify the user by the <code>id_rsa_git.pub<\/code> key supplied and then tunnel the user into a restricted git shell with a virtual git identity.<\/p>\n<p>If you later want to access a git repo on the server, you can access it by simply typing:<\/p>\n<pre class=\"lang:default decode:true\" title=\"git invocation using ~\/.ssh\/config settings\">ilek@i7:~$ git clone root@git:reponame\r\n<\/pre>\n<p>git will pass the login to ssh which will then revert to its <code>config<\/code> file, see that <code>root@git<\/code> matches the <code>Host git<\/code> entry and automatically select the <code>id_rsa_git<\/code> key pair.<\/p>\n<p>For later purposes in the setup process, <code>scp<\/code> the <code>id_rsa_git.pub<\/code> key from your client&#8217;s <code>~\/.ssh<\/code> directory to the <code>\/root<\/code> directory of your OpenWRT machine.<\/p>\n<h3>In case you are only a (future) git User and not ADMIN of the oWRT device<\/h3>\n<p>If you are not an administrator of the oWRT device hosting the git server, you can simply use your default ssh key to be identified as a git user. As the authorized_keys file on the oWRT machine does not contain this key, there won&#8217;t be any collision. Just send your <code>~\/.id_rsa.pub<\/code> key to the oWRT\/git admin who will then add it to gitolite.<\/p>\n<h1>Installing gitolite on the OpenWRT server<\/h1>\n<p>Once you have completed the preliminary steps, installing gitolite is quite easy.<\/p>\n<h3>Preliminary work<\/h3>\n<p>Log into the oWRT device as root and <code>cd<\/code> to the <code>\/root<\/code> directory and rename the public key file you scp&#8217;ed from the client machine to <code>gitadmin.pub<\/code> (or whatever else you would like to be the login name for the git administrator).<\/p>\n<h3>Core installation<\/h3>\n<p>Then issue the following commands:<\/p>\n<pre class=\"lang:default decode:true\" title=\"Installation of gitolite\">cp -p \/etc\/dropbear\/authorized_keys \/etc\/dropbear\/authorized_keys_backup\r\ngit clone git:\/\/github.com\/sitaramc\/gitolite\r\nmkdir -p \/root\/.gitolite\/logs\r\ngitolite\/install -ln \/usr\/bin\r\ngitolite setup -pk gitadmin.pub\r\nrm gitadmin.pub<\/pre>\n<h3>Post Install Tweaks<\/h3>\n<p>There are two things which still need to be tweaked:<\/p>\n<p>The first one is that gitolite stores the <code>authorized_keys<\/code> file under <code>\/root\/.ssh<\/code>, but oWRT&#8217;s dropbear expects the file to be in <code>\/etc\/dropbear<\/code>. As shown in the oWRT documentation, this can be solved by creating a symlink:<\/p>\n<pre class=\"lang:default decode:true \" title=\"symlinking authorized keys\">rm \/etc\/dropbear\/authorized_keys\r\nln -s \/root\/.ssh\/authorized_keys \/etc\/dropbear\/authorized_keys<\/pre>\n<p>Do not forget to copy back the content of the <code>\/etc\/dropbear\/authorized_keys_backup<\/code> to the <code>authorized_keys<\/code> file (you can vim-edit the file both from <code>\/etc\/dropbear<\/code> and from <code>\/root\/.ssh<\/code>). Once again: <strong>Do not forget this step<\/strong> or you risk shutting yourself out from your oWRT box.<\/p>\n<p>The second problem is something I stumbled accross <a href=\"https:\/\/groups.google.com\/forum\/#!topic\/gitolite\/qM5H3Echv74\" target=\"_blank\">here<\/a>. Apparently gitolite tends to &#8220;recreate&#8221; its own version of the <code>authorized_keys<\/code> file with each git push. That is exactly what we do <strong>not<\/strong> want as this will delete any root user keys we just restored from <code>authorized_keys_backup<\/code>. The solution is as follows:<\/p>\n<pre class=\"lang:default decode:true \" title=\"Preventing gitolite from recreating the authorized_keys file\">cd \/root\r\nmkdir -p local\/triggers \r\n<\/pre>\n<p>Then create a script file with the following content:<\/p>\n<pre class=\"lang:default decode:true \" title=\"Relink authorized_keys file\">#!\/bin\/ash\r\nln -sf ~\/.ssh\/authorized_keys \/etc\/dropbear<\/pre>\n<p>Make the file executable:<\/p>\n<pre class=\"lang:default decode:true \">chmod +x local\/triggers\/link-akf<\/pre>\n<p>Edit <code>.gitolite.rc<\/code> as follows:<\/p>\n<ul>\n<li>Uncomment the line<br \/>\n<code>LOCAL_CODE \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0=&gt; \u00a0\"$ENV{HOME}\/local\",<\/code><\/li>\n<li>Immediately below that line add a line with the following content:<br \/>\n<code>NON_CORE =&gt; 'ssh-authkeys POST_COMPILE link-akf',<\/code><\/li>\n<\/ul>\n<h1>Testing and configuring<\/h1>\n<h2>Check the authorized_keys file<\/h2>\n<p>If everything worked correctly, your <code>\/etc\/dropbear\/authorized_keys<\/code> file should contain your standard ssh keys <strong>and<\/strong> a section which looks as follows:<\/p>\n<pre class=\"lang:default decode:true\" title=\"authorized_keys after initial gitolite setup\"># gitolite start\r\ncommand=\"\/root\/gitolite\/src\/gitolite-shell gitadmin\",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza ... and the remainder of the public key\r\n# gitolite end\r\n<\/pre>\n<h2>Check if you can clone a repo from the server to the client machine<\/h2>\n<p>During the setup, gitolite has created two repositories: <code>gitolite-admin<\/code> and <code>testing<\/code>. The <code>testing<\/code> repo is read\/write for any registered gitolite user while the <code>gitolite-admin<\/code> repo can only be accessed by the <code>gitadmin<\/code> user we specified during the setup. You should now be able to clone the gitolite-admin repo from your client machine:<\/p>\n<pre class=\"lang:default decode:true\" title=\"Cloning gitolite-admin from the server\">ilek@i7:\/media\/ramdisk$ git clone root@git:gitolite-admin\r\nCloning into 'gitolite-admin'...\r\nremote: Counting objects: 21, done.\r\nremote: Compressing objects: 100% (19\/19), done.\r\nReceiving objects: 100% (21\/21), 3.12 KiB | 0 bytes\/s, done.21\/21)   \r\nResolving deltas: 100% (3\/3), done.\r\n0 (delta 0)\r\nChecking connectivity... done.\r\n<\/pre>\n<h2>Adding a user and setting permissions<\/h2>\n<p>If you want to add another user, you just take the new user&#8217;s public ssh key, rename it to <code>&lt;username&gt;.pub<\/code> and copy it to the <code>gitolite-admin\/keydir<\/code>. Then run the following conventional git commands:<\/p>\n<pre class=\"lang:default decode:true \" title=\"Adding a user to gitolite\">git add &lt;username&gt;.pub\r\ngit commit -m \"User &lt;username&gt; added\"\r\ngit push origin master<\/pre>\n<p>In order to conduct the next test, you should add another user from another machine who will not be admin (neither for oWRT, nor by gitolite; we just want a plain and simple git user who has access to the testing repo). Access rights to the repositories can be granted or withdrawn by editing the g<code>itolite-admin\/conf\/gitolite.conf<\/code> file (which is pretty self-explanatory).<\/p>\n<h2>Check if git users are really ring-fenced from root access<\/h2>\n<p>Finally you should check if git users who log in through the root ssh access are not able to get access to the root shell &#8211; after all you want to be sure that git users cannot execute root commands on your server. With the gitolite account just created, try the following:<\/p>\n<pre class=\"lang:default decode:true \" title=\"Testing gitolite for ssh security\">ssh root@&lt;oWRT-IP&gt;\r\n<\/pre>\n<p>If everything is fine, you should see a message like this:<\/p>\n<pre class=\"lang:default decode:true \" title=\"ssh reject for gitolite user\">PTY allocation request failed for channel 0\r\nsh: hello, &lt;username&gt;, this is root@ running gitolite3 v3.6.3-11-g247156 on git 2.0.0\r\n\r\nhostname: not found\r\n R W testing\r\nConnection to &lt;oWRT-IP&gt; closed<\/pre>\n<p>If you see your normal oWRT welcome screen after the login, then something has gone awfully wrong and gitolite users can access the root functionalities of your OpenWRT operating system. In that case you should delete the complete gitolite installation from your server and restore the <code>authorized_keys<\/code> file from the backup file you made.<\/p>\n<pre class=\"lang:default decode:true \" title=\"Removing gitolite from the server\">cd \/root\r\nrm -rf .gitolite gitolite\r\nrm .gitconfig\r\ncd \/etc\/dropbear\r\ncp authorized_keys_backup authorized_keys<\/pre>\n<h1>Using git(olite) with Eclipse<\/h1>\n<p>Once you have a repo on gitolite, it is convenient to directly connect it to a programming IDE like Eclipse. On your local machine, proceed as follows:<\/p>\n<h2>Setting up Eclipse for gitolite<\/h2>\n<p>Click <code>Window<\/code> \/ <code>Preferences<\/code> and navigate to <code>Network Connections<\/code> \/ <code>SSH2<\/code>:<img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-726\" src=\"http:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_network_conn.png\" alt=\"eclipse_network_conn\" width=\"600\" height=\"313\" srcset=\"https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_network_conn.png 600w, https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_network_conn-300x157.png 300w, https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_network_conn-500x261.png 500w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/p>\n<p>Enter the ssh home directory (which is usually under ~\/.ssh for Linux machines) and the <strong>private<\/strong> key name. If you are on a machine with both root and git access make sure, that it is the git key and not the default key.<\/p>\n<p>Then click the <code>Key Management<\/code> tab, press the <code>Load Existing Key<\/code> and navigate to the <strong>public<\/strong> key which corresponds to the private key you specified in the previous tab.<\/p>\n<h2>Importing a repository from gitolite into Eclipse<\/h2>\n<p>Once you have estabished the connection, you can easily import a project from your gitolite server.\u00a0 We are going to import the (empty) testing repository as a Java project and add one file.<\/p>\n<ul>\n<li>Choose <code>File<\/code> \/ <code>Import<\/code> from Eclipse&#8217;s menu,<\/li>\n<li>choose <code>Git<\/code> \/ <code>Projects<\/code> from Git in the following dialog and click <code>Next<\/code>,<\/li>\n<li>choose <code>Clone URI<\/code> and click <code>Next<\/code> again.<\/li>\n<\/ul>\n<p>In the dialog that opens now,<\/p>\n<ul>\n<li>fill in the <strong>Host<\/strong> field with the IP Address of your Git Server (or the FQDN),<\/li>\n<li>the <strong>Repository Path<\/strong> with the name of the repository you want to clone (<code>testing<\/code> in our case),<\/li>\n<li>Set the <strong>Protocol<\/strong> to ssh,<\/li>\n<li>and enter the <strong>User<\/strong> name &#8211; which in case of our OpenWRT installation should be <code>root<\/code> (remeber that gitolite always clears through a central user and uses the ssh key to map the central user to the actual gitolite user)<\/li>\n<li>the <strong>URI<\/strong> field is filled automatically, the <strong>Port<\/strong> and <strong>Password<\/strong> fields remain empty<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-727\" src=\"http:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_git_location.png\" alt=\"eclipse_git_location\" width=\"600\" height=\"582\" srcset=\"https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_git_location.png 600w, https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_git_location-300x291.png 300w, https:\/\/hobbykeller.spdns.de\/wp-content\/uploads\/2015\/10\/eclipse_git_location-309x300.png 309w\" sizes=\"auto, (max-width: 600px) 100vw, 600px\" \/><\/p>\n<p>After clicking <code>Finish<\/code> you will come to a dialog in which Eclipse warns you that you import an empty repository &#8211; nothing to worry about as gitolite has set up the testing repository without any content.<\/p>\n<p>The New Project Wizard will then take over. Choose Java for this example, give a meaningful project name and hit <code>Finish<\/code> again.<\/p>\n<p>Once you have finished that procedure, Eclipse will have cloned a local copy of your git repository to your client. You can work on that copy as before.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you want do serious programming, you sooner or later need to work with a version control system such as Subversion, Mercrurial or &#8211; probably the best choice &#8211; git.<span class=\"more-button\"><a href=\"https:\/\/hobbykeller.spdns.de\/?p=718\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\">Running a git server on OpenWRT<\/span><\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[64,16],"tags":[137,135,136,17],"class_list":["post-718","post","type-post","status-publish","format-standard","hentry","category-linux","category-openwrt","tag-eclipse","tag-git","tag-gitolite","tag-openwrt"],"_links":{"self":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/718","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=718"}],"version-history":[{"count":10,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/718\/revisions"}],"predecessor-version":[{"id":960,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=\/wp\/v2\/posts\/718\/revisions\/960"}],"wp:attachment":[{"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=718"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=718"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hobbykeller.spdns.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=718"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}