In June I described how one of the new OwnTracks features we released is the possibility of defining Points of Interest in the app (currently iOS only) which become associated with the location being published and are part of the JSON payload submitted to the OwnTracks back-end. Our Frontend also renders POI on the map.
I’ve had a little bit of a bee in my bonnet for some months now, and in November I asked Christoph whether it would be possible to submit a photo from within the app itself.
We discussed this (mainly in person) there and back, and came to the conclusion that transmitting the whole photograph as part of an OwnTracks message payload would be overkill; most people likely already have some method of organizing photos and likely wouldn’t want us to invent another.
Instead, the way it’s currently slated for release is, that I take a photo using the normal iOS mechanisms to do this, and from within OwnTracks I can submit a POI (Point of Interest) with an associated image; the image is tagged with the file name of the photo.
On the map I choose to publish a new location.
By tapping on Set POI with image I get to a new dialog which lets me select an image from the photos library and set a POI text, and the POI itself is shown on the Friend’s details page
and the map displays the thumbnail of the photo
This thumbnail will also be shown on Friends’ maps.
As mentioned above, our "_type" : "location" JSON payload is augmented with the image name, a POI text, and the image data of the thumbnail:
{
"_type": "location",
"acc": 5,
"alt": 0,
"conn": "w",
"created_at": 1734377867,
"image": "/9j/42nS1Xn ... JfVKcX0R5mIy9+813P/9k=",
"imagename": "IMG_0009",
"lat": 52.085284,
"lon": 5.120975,
"m": 1,
"poi": "fabulous rijsttafel",
"t": "u",
"tid": "JJ",
"tst": 1734377712
}
The Recorder’s API will return these larger payloads transparently.
We’re wrapping this up as we speak and it could be hitting an App Store near you in the next few days.
Inspired by Martin’s toolkit review, and because I’ve occasionally been stuck wanting to fix something but couldn’t, I now have a small kit of tools which I’ll typically have in my bag when out of the house.
Most of the tools should be self-explanatory. The terminal blocks and the two WAGO spring clamps have helped me with cabling in the boot of the car in the past, and I’ll use the UHU superglue to fix your mug. (Beverage container, obviously.)
The Wera is quite a versatile driver, the content of which can be seen here.
I dug into GNOME’s keyring a bit in order to find a way on Linux to implement the portion of my otp shell script which obtains the age private key for decripting TOTP codes on the command line.
GNOME Keyring is “a collection of components in GNOME that store secrets, passwords, keys, certificates and make them available to applications. It is integrated with the user’s login, so that their secret storage can be unlocked when the user logins into their session”. libsecret is library for storing and retrieving passwords and other secrets. It communicates with the “secrets” service using D-Bus which stores them in ~/.local/share/keyrings/.
It turns out there’s a program called Seahorse I can install to edit such passwords, which I did. (The program seems a bit simplistic; for instance I can use it to generate SSH keys, but cannot import them …)
Using lssecret I see the entry and its password are definitely there, but I can’t use secret-tool to lookup the entry. However, if I create an entry using that utility, I can look it up. What gives?
$ lssecret -s
Item: lemonade shop
Secret: oranges42
Key: xdg:schema
Value: org.gnome.keyring.Note
There are no visible attributes associated with the password when added in Seahorse
Colin Vidal phrases what I so far deduce:
my understanding is that secret-tool enforces usage of attributes/values pair (shown as “Details” in seahorse) for store/read operations. But adding a “Password” in seahorse doesn’t set any.
And that is so. If, as mentioned earlier, I use secret-tool to create the entry giving it any number of attribute / value pairs, I can then look up the entry using one or more of those pairs; note that there can be several with the same attribute / value; a search with --all finds them. Thanks also to Ben Hardill who links to a description that confirms this.
From here I learn:
Each password in a keyring has a set of attributes. These attributes used to find that specific password later. Attributes are either a string or a unsigned integer.
$ secret-tool store --label="Jane's Pearls" domain example.org type doorlock username jane
Password:
$ lssecret -s
Item: Jane's Pearls
Secret: oops!
Key: xdg:schema
Value: org.freedesktop.Secret.Generic
Key: domain
Value: example.org
Key: type
Value: doorlock
Key: username
Value: jane
$ secret-tool search --all username jane
[/10]
label = Jane's Pearls
secret = oops!
created = 2024-10-24 05:45:34
modified = 2024-10-24 05:45:34
schema = org.freedesktop.Secret.Generic
attribute.domain = example.org
attribute.type = doorlock
attribute.username = jane
$ secret-tool lookup domain example.org
oops!
So, this last command is what I will use to lookup the age key I require.
Ansible
This could also come in handy for use with Ansible, say. For instance:
$ secret-tool store --label=Ansible service ansible-playbook username jane
Password:
It took me a bit to find: the terms "service" and "username" are used by the lookup because Python keyring uses these in its libsecret backend. From the plugin source:
for term in terms:
(servicename, username) = (term.split()[0], term.split()[1])
display.vvvv(u"username: %s, servicename: %s " % (username, servicename))
password = keyring.get_password(servicename, username)
if password is None:
raise AnsibleError(u"servicename: %s for user %s not found" % (servicename, username))
We can then retrieve the variable in a playbook using c.g.keyring lookup: the term ansible-playbook is the service and jane is the username as specified in the store command earlier:
lookup('community.general.keyring', 'ansible-playbook jane')
And by the way, installing Python keyring makes available a command-line utility of the same name which can access any of the supported backends. For my Linux system I can therefore set and get this secret more easility than with secret-tool:
$ keyring get ansible-playbook jane
oopsie22
keyring also works on macOS where it uses Keychain Access to store secrets. I can add such a secret with keyring set whereupon I see the following entry created in KeyChain:
By default Python.app is granted access to the entry, but if I revoke that a keychain get will have the OS request permission from me:
Further reading
An exciting aspect about teaching is “what questions will I get today?”, and I wasn’t disappointed when a student asked:
Why was a dot chosen to separate labels in presentation for DNS names?
I mumble something about it being neater than a ‘#’ and less strange than a ‘$’ and that it’s easy to type on a US keyboard, but I really don’t know and say so. I put it aside and later looked through RFC 1034 and RFC 1035 and didn’t find an answer, so I asked on the Fediverse, and got a lot of feedback.
I’ve had bad experience linking to social media accounts, so I’m going to refer to contributors by their first names; you’ll know who you are.
First off, Hans suggested it might be something about connecting the dots; cute, but ‘no’. ;)
Ed refers to dots used in hostnames, and indeed, old host.txt files from 1988 contain names with dots, and Paul H. adds that this 1985 hosts.txt is the first to use dots.
...
HOST : 18.27.0.23 : MIT-DAFFY-DUCK.ARPA,MIT-DAFFY-DUCK,DAFFY-DUCK,DAFFY : SYMBOLICS-3600 : LISPM : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/TIME,TCP/FINGER,UDP/TIME,UDP/TFTP,UDP/FINGER :
HOST : 18.10.0.24 : MIT-NMS.ARPA,MIT-NMS,NMS : PDP-11 : NMS ::
...
The plot thickens.
Jeroen suggests contacting Paul Mockapetris who is well known as the person who invented the DNS (with others), and links him to the Mastodon thread. At least we got Paul to create an account there, though I’ve not otherwise heard back from the gentleman.
Martin points out that the 1983 RFC 881 already accepts the dot as given and likewise assumes a mundane reason based on keyboard layouts. I laugh when he rightly points out that the name of the file hosts.txt also contains a dot.
Florian brings on a comparison to quad dotted decimal IP addresses, and looking back it seems that the 1981 RFC 780 (Mail Transfer Protocol), might be the first mention with
Another form is four small decimal integers separated by dots and enclosed by brackets, e.g., “[123.255.37.321]”, which indicates a 32 bit ARPA Internet Address in four eight bit fields.
Paul W. has a good point when he says
we use it between sentences. It’s small, and clear and visually presents a good divider and commonly in use already
And finally I ask a medium which is omnipresent in today’s world and get the following response which sounds good but sadly lacks in naming sources for its answers, as it always does:
When DNS was first developed in the early 1980s, designers of the system had to choose a character to serve as the separator. The dot was chosen because it is a simple, non-alphanumeric character that wasn’t typically used in regular hostnames or labels themselves.
Additionally, dots are easy to read and visually distinct, making domain names easy to parse by both humans and machines.
Later Guillaume-Jean suggests a possible flash of genius:
What if this comes from VMS (VAX computers OS) that uses “.” as path separator? Those machine were popular in ARPANet/early Internet days and the analogy between hierarchical file system and #DNS could make sense.
Some of you might recall a similar question nine years ago, when we researched why the comment character in a DNS zone master file is a semicolon.
Via Hugo I saw a question on whether anybody had an example of DNSviz rendering a revoked KSK, and that tickled my fancy, as I’d not actually seen one on that marvelous platform.
As I have a local copy of dnsviz running here, I thought I’d quickly set it up by creating a zone with a CSK and a revoked CSK (note the keytag/keyId changes when revoking a KSK).
$ dnssec-keygen -a13 -fk xexample.aa
Generating key pair.
Kxexample.aa.+013+06060
$ dnssec-revoke Kxexample.aa.+013+06060.
Kxexample.aa.+013+06188
I signed the zone, loaded it into a BIND name server (the brand is not relevant), and configured dnsviz to probe and graph the zone.
$ z=xexample.aa
$ dnsviz probe -A \
-x aa+:mini.aa=127.0.0.2:53 \
--pretty-output \
-o $z.json \
$z
Analyzing aa (stub)
Analyzing xexample.aa
$ dnsviz graph -r $z.json -T html -O --rr-types NS --rr-types SOA
The result is pretty much what I expected
although I had hoped the colour of a revoked key would be different so as to quickly identify it without hovering over it. :)
It’s hard to put into words how much I appreciate the work people invested into DNSviz.
Other recent entries
