" | append: "
" %} {% assign summary_length = site.blog_summary_length | default: 50 %} {% assign ignore = include.ignore | default: site.blog_ignore | split: ',' %} {% assign summary_headings = site.blog_summary_headings %} {% assign heading_summary = include.heading_summary %} {% assign newline = ' ' %}subscribe via RSS
================================================ FILE: _includes/search.html ================================================ {% unless include.js == false %} {% endunless %} {% unless include.template == false %} {% endunless %} ================================================ FILE: _includes/search_json.html ================================================ {% assign _words = "" %}{% assign _wordlists = "" | split: "," %}{"pages": [ {% capture _docs %}{% include search_json_items.html type="doc" %}{% endcapture %}{% assign _docs = _docs | strip %}{% capture _pages %}{% include search_json_items.html pages=site.html_pages type="page" %}{% endcapture %}{% assign _pages = _pages | strip %} {{ _docs }}{% if _docs != "" and _pages != "" %},{% endif %}{{ _pages }} ]} ================================================ FILE: _includes/search_json_items.html ================================================ {% capture codeblock %} {% assign docs = include.pages | default: site.documents %} {% assign _type = include.type | default: 'doc' %} {% assign _first = true %} {% endcapture %} {% for _page in docs %}{% capture codeblock %} {% assign _content = _page.content | strip_html | markdownify | strip_html | remove: site.excerpt_separator | strip %} {% if _page.summary %} {% assign _blurb = _page.summary %} {% else %} {% if _content contains site.excerpt_separator %} {% assign _blurb = _content | split: site.excerpt_separator | first %} {% else %} {% assign _blurb = _content %} {% endif %} {% endif %} {% if _type == 'page' %} {% assign fallback_title = _page.content | split: "" | first | strip_html | truncatewords: 10 | strip %} {% assign _blurb = _blurb | replace_first: fallback_title, '' %} {% endif %} {% if _page.date %} {% assign _date_parts = _page.date | date: '%Y %B %-d' %} {% endif %} {% assign _wordlist = _content | append: " " | append: _page.title | append: " " | append: _page.tags | append: " " | append: _page.category | append: " " | append: _page.url | append: " " | append: _page.author | append: " " | append: _page.summary | append: " " | append: _date_parts | downcase | remove: '!' | remove: '"' | remove: '#' | remove: '$' | remove: '%' | remove: '&' | remove: '(' | remove: ')' | remove: '[' | remove: ']' | remove: '*' | remove: '+' | remove: ',' | remove: ';' | remove: '=' | remove: '?' | remove: '“' | remove: '”' | replace: "‘", "'" | replace: "’", "'" | replace: "'s ", " " | replace: " '", " " | replace: "' ", " " | replace: '-', ' ' | replace: '–', ' ' | replace: '—', ' ' | replace: '@', ' ' | replace: '...', ' ' | replace: '…', ' ' | replace: '.', ' ' | replace: '/', ' ' | replace: ':', ' ' | replace: ',', ' ' | split: ' ' | sort | uniq | where_exp: "item", "item.size > 2" | where_exp: "item", "item.size < 21" %} {% assign _wordlist_string = _wordlist | join: ',' %} {% assign _words = _words | append: "," | append: _wordlist_string %} {% assign _wordlists = _wordlists | push: _wordlist %} {% assign _id = forloop.index | minus: 1 %} {% endcapture %}{% assign codeblock = nil %}{% unless _page.index == false %}{% if _first == false %},{% endif %}{ "id": {{ _id }}, "title": {{ _page.title | strip | default: fallback_title | jsonify }}, "slug": {{ _page.slug | strip | jsonify }}, "url": "{{ site.baseurl }}{{ _page.url }}", "type": {{ _type | jsonify }}, "category": {{ _page.category | join: "," | strip | jsonify }}, "tags": {{ _page.tags | join: "," | strip | replace: ", ", "," | replace: ",,", "," | downcase | split: "," | sort | uniq | jsonify }}, {% if _page.date %} "date" : "{{ _page.date | date_to_xmlschema }}", "datestring" : "{{ _page.date | date: '%A %-d %B %Y' }}", {% endif %} "wordcount": {{ _content | remove: site.excerpt_separator | number_of_words }}, "wordlist": {{ _wordlist | join: " " | jsonify }}, "summary": {{ _blurb | replace: "\n", " " | strip | truncatewords: 50 | jsonify }} }{% assign _first = false %}{% endunless %}{% endfor %} ================================================ FILE: _includes/twitter.html ================================================ {% assign id = include.id | default: config.twitter_id %} {% assign _account = include.account | default: config.twitter_username %} {% assign limit = include.limit | default: 3 %} {% if include.id %}| Time Zone | |
| New Zone | |
{
"command": "open",
"channel": "mychannel",
"payload": "echo"
}
Now we're ready to play ... Well almost.
The very first control message sent to and from `cockpit-bridge` should be an `"init"` message containing a version number. That version number is `1` for the foreseeable future.
{
"command": "init",
"version": 1
}
Try it out
----------
So combining our knowledge so far, we can run the following:
```text
$ cockpit-bridge --interact=----
```
In this debugging mode sent by `cockpit-bridge` will be bold in your terminal. Now paste the following in:
{ "command": "open", "channel": "mychannel", "payload": "echo" }
----
mychannel
This is a test
----
You'll notice that `cockpit-bridge` sends your message back. You can use this technique to experiment. Unfortunately
`cockpit-bridge` exits immediately when it's stdin closes, so you [can't yet use shell redirection from a file effectively](https://github.com/cockpit-project/cockpit/issues/1594).
Making a DBus method call
-------------------------
To make a DBus method call, we open a channel with the payload type `"dbus-json3"`. Then we send JSON messages as payloads inside that channel. An additional field in the `"open"` control message is required. The `"name"` field is the bus name of the DBus service we want to talk to:
{
"command": "open",
"channel": "mydbus",
"payload": "dbus-json3",
"name": "org.freedesktop.hostname1"
}
Once the channel is open we send a JSON object as a payload in the channel with a `"call"` field. It is set to an array with the DBus interface, DBus object path, method name, and an array of arguments.
mydbus
{
"call": [ "/org/freedesktop/hostname1", "org.freedesktop.hostname1",
```unknown
"SetStaticHostname", [ "mypinkpony.local", true ] ],
"id": "cookie"
}
```
If we want a reply from the service we specify an `"id"` field. The resulting `"reply"` will have a matching `"id"` and would look something like this:
mydbus
{
"reply": [ null ],
"id": "cookie"
}
If an error occurred you would see a reply like this:
mydbus
{
"error": [
```unknown
"org.freedesktop.DBus.Error.UnknownMethod",
[ "MyMethodName not available"]
],
"id":"cookie"
}
```
This is just the basics. You can do much more than this with DBus, including watching for signals, lookup up properties, tracking when they change, introspecting services, watching for new objects to show up, and so on.
Spawning a process
------------------
Spawning a process is easier than calling a DBus method. You open the channel with the payload type `"stream"` and you specify the process you would like to spawn in the `"open"` control message:
{
"command": "open",
"channel": "myproc",
"payload": "stream",
"spawn": [ "ip", "addr", "show" ]
}
The process will send its output in the payload of one or more messages of the `"myproc"` channel, and at the end you'll encounter the `"close"` control message. We haven't looked at until now. A `"close"` control message is sent when a channel closes. Either the `cockpit-bridge` or its caller can send this message to close a channel. Often the `"close"` message contains additional information, such as a problem encountered, or in this case the exit status of the process:
{
"command": "close",
"channel": "myproc",
"exit-status": 0
}
Doing it over a WebSocket
-------------------------
Obviously in Cockpit we send all of these messages from the browser through a WebSocket hosted by `cockpit-ws`. `cockpit-ws` then passes them on to `cockpit-bridge`. You can communicate this way too, if you [configure Cockpit to accept different Websocket Origins](https://cockpit-project.org/guide/cockpit.conf.5.html).
And on it goes
--------------
There are payload types for reading files, replacing them, connecting to unix sockets, accessing system resource metrics, doing local HTTP requests, and more. Once the protocol is stable, solid documentation is in order.
I hope that this has given some insight into how Cockpit works under the hood. If you're interested in using this same protocol, I'd love to get feedback ... especially while the basics of the protocol are not yet frozen.
================================================
FILE: _posts/2015-06-09-cockpit-does-kubernetes.md
================================================
---
title: Cockpit's Kubernetes Dashboard
date: 2015-06-09 23:51
tags: cockpit technical kubernetes
slug: cockpit-kubernetes-dashboard
category: release
---
Here's a video showing what I've been working on together with some help from a couple Cockpit folks. It's a [Cockpit](https://cockpit-project.org) dashboard for Kubernetes.
If you haven't heard about [Kubernetes](http://kubernetes.io/) ... it's a way to schedule docker containers across a cluster of machines, and take care of their networking, storage, name resolution etc. It's not completely baked, but pretty cool when it works.
The Cockpit dashboard you see in the video isn't done by any means ... there's a lot missing. But I'm pretty happy with what we have so far. I'm using Cockpit 0.61 in the demo. There are some nagging details to make things work, but hopefully we can solve them later. The Nulecule support isn't merged yet, [Subin has been working on it](https://github.com/cockpit-project/cockpit/pull/2332).
The Cockpit dashboard actually mostly works with [Openshift v3](https://github.com/openshift/origin). Openshift v3 is based on Kubernetes underneath, which makes apps that are developed there really portable.
================================================
FILE: _posts/2015-07-10-rest-api-plugin.md
================================================
---
title: Making REST calls from Javascript in Cockpit
date: '2015-07-10'
category: tutorial
tags: cockpit linux
slug: making-rest-calls-from-javascript-in-cockpit
---
*Note: This post has been updated for changes in Cockpit 0.90 and later.*
{:.note}
[Cockpit is a user interface for servers](https://cockpit-project.org). In [earlier](https://cockpit-project.org/blog/creating-plugins-for-the-cockpit-user-interface.html) [tutorials](https://cockpit-project.org/blog/using-dbus-from-javascript-in-cockpit.html) there's a guide on how to add components to Cockpit.
Not all of the [system APIs use DBus](https://cockpit-project.org/blog/d-bus-is-powerful-ipc.html). So sometimes we find ourselves in a situation where we have to use REST (which is often just treated as another word for HTTP) to talk to certain parts of the system. For example [Docker has a REST API](https://docs.docker.com/reference/api/docker_remote_api/).
For this tutorial you'll need at least Cockpit 0.58. There was one last tweak that helped with the ```superuser``` option you see below. You can install it in [Fedora 22](https://cockpit-project.org/running.html) or [build it from git](https://github.com/cockpit-project/cockpit/blob/master/HACKING.md).
Here we'll make a package called *docker-info* which shows info about the docker daemon. We use the `/info` [docker API](https://docs.docker.com/reference/api/docker_remote_api_v1.18/#display-system-wide-information) to retrieve that info.
I've prepared the [docker-info package here](https://cockpit-project.org/files/docker-info.tgz). It's just two files. To download them and extract to your current directory, and installs it as a Cockpit package:
```text
$ wget https://cockpit-project.org/files/docker-info.tgz -O - | tar -xzf -
$ cd docker-info/
$ mkdir -p ~/.local/share/cockpit
$ ln -snf $PWD ~/.local/share/cockpit/
```
Previously we [talked about](https://cockpit-project.org/blog/creating-plugins-for-the-cockpit-user-interface.html) how packages are installed, and what `manifest.json` does so I won't repeat myself here. But to make sure the above worked correctly, you can run the following command. You should see `docker-info` listed in the output:
```text
$ cockpit-bridge --packages
...
docker-info: .../.local/share/cockpit/docker-info
...
```
If you're logged into Cockpit on this machine, first log out. And log in again. Make sure to log into Cockpit with your current user name, since you installed the package in your home directory. You should now see a new item in the *Tools* menu called *Docker Info*:
After a moment, you should see numbers pop up with some stats about the docker daemon. Now in a terminal try to run something like:
```text
$ sudo docker run -ti fedora /bin/bash
```
You should see the numbers update as the container is pulled and started. When you type ```exit``` in the container, you should see the numbers update again. How is this happening? Lets take a look at the `docker-info` HTML:
```html