Radio silence

Aug. 16th, 2017 11:10 am
[syndicated profile] charlie_stross_diary_feed

Hi! Apologies for the long hiatus. I've been kind of preoccupied, with a funeral in the family and then a world science fiction convention in Helsinki, but I'm finally home and trying to get back to some semblance of normal.

In the meantime, some news:

If you're in the United States and read ebooks, The Rhesus Chart is currently discounted to $1.99. (The link goes to but it should be the same price on iBooks and the Google Play store and Kobo. It's probably also at this price in Canada, but not in the UK or Europe--different publishers in different territories.) If you haven't tried the Laundry Files, this book isan entrypoint: why not give it a try?

Tonight, August 16th, I'm appearing at the Edinburgh Book festival with Nnedi Okorafor, Jo Walton, and Ken Macleod. We'll be at the Studio Theatre from 7:15pm; it's a ticketed event from the main book festival box office.

And on Friday August 18th, I'll be back at the book festival for a discussion with Nalo Hopkinson, Ken MacLeod, and Ada Palmer: we'll e at Bosco Theatre (on George Street) from 6:30pm, and again, it's a ticketed event.

And finally, the big news: my space opera, Ghost Engine, is being rescheduled for 2019; instead, July 2018 should see publication of The Labyrinth Index, the ninth Laundry Files novel! Publishers will be Orbit in the UK and Tor in the USA (this being the New Normal for the Laundry Files). This change has been in the works for a few months, but I didn't want to pre-announce it until I had it nailed down. (In a nutshell: Ghost Engine was too ambitious to finish on my original schedule, and The Labyrinth Index was growing more and more timely, until they just crossed over.)

[syndicated profile] linode_status_new_feed

Posted by Linode

Aug 15, 23:34 UTC
Resolved - Since we have not experienced further issues with the Linode Manager, API, or Tokyo 2 connectivity, this matter is now resolved.
If you experience any further issues, please reach out to our Customer Support Team for assistance.

Aug 15, 21:26 UTC
Monitoring - At this time we have been able to correct the issues affecting boot and shutdown processes with the Linode Manager and our API. We will be monitoring this issue to ensure these processes remain stable. If you are still experiencing issues with the Linode Manager or our API, please email our Customer Support Team at for assistance.

Aug 15, 20:28 UTC
Investigating - We are currently experiencing issues affecting boot and shutdown processes with the Linode Manager and our API. This issue is primarily affecting Linodes in the Tokyo 2 data center at this time. Our team is investigating this issue and we will provide additional updates as this incident develops.
If you are experiencing issues with your Linode, please email our Customer Support Team at

vatine: books-related stuff (books)
[personal profile] vatine

Third and most probably final volume of Kress' Probability series. Starts about, oh, 2-3 years after Probability Sun. Again, features and ensemble cast. Again, I can't say jack without spoiling the previous volumes.

And, possibly boringly, again eminently readable.

On the up-side, I am now caught up to "now", having carefully rationed up the last week-and-a-half's write-ups over two days. Go me!
vatine: books-related stuff (books)
[personal profile] vatine

The sequel of Probability Moon in what I have chosen to call (don't recall if there's a proper name) Kress' Probability series.

We continue the multi-viewpoint narrative, as a group of intrepid scientists (and military) return to World, where they expect to be solidly classed as "unreal". Things happen, science is done, setting the scene for the third book of the series.

I wish there was anything cogent I could say about this that would not simply be stomping all over the reading of #1 in the series, but that's pretty much it.

Still, a rather pleasant read, all things considered.
vatine: books-related stuff (books)
[personal profile] vatine

It's been a few years since I read this, I think. All in all, eminently readable.

We're flipping between viewpoint characters, sometimes we're following Enli pek Brimmidin (I am now unsure if it's "pek" or "Pek"), a woman from World who's been declared temporarily unreal, for having done unreal things, thus violating Reality.

Sometimes, we're following one of a few Earth scientists, on World, trying to figure out things like "how does shared Reality work" and "that mountain over there is mighty strange, I wonder why". And we also have a bunch of Earth military going "that is not a moon, it's an artefact!"[*].

All in all, eminently readable, happy I decided it was the next to push into the queue.

[*] That may look like, but isn't, a spoiler. You're told this in the first 15-20 pages, IIRC.
vatine: books-related stuff (books)
[personal profile] vatine
Previously unread.

This is an entry out of sequence, but there's too much to clean up to make it worth sorting numbers out, sorry.

Where was I? Ah, yes, this is set in the same fictional universe as Seeing Red, but takes a completely different tack. We follow a young woman, who after a very mysterious aviation accident find herself not at ALL in her familiar Australia, but in a hilly, rain-foresty elsewhere. Adventure and perhaps a little romance happens, and so forth.

I suspect it's one of those that grow with repetitions, but even so I found it quite readable with a sense of "OK, now what?" when over and a "just a few more pages..." when reading.

Claims to be a first in the (sub?) series it's in, Return of the Aghyrians.
vatine: books-related stuff (books)
[personal profile] vatine

Second book in Mckenna's Tales of Einarinn series. We continue the narrative style from installment #1, where we have a primary POV character using the first person and occasionally having other viewpoint characters, where the third person is used.

I am in a little bit of "catch-up" mode at the moment, but essentially this was pretty good reading. Perhaps not surprising, as I'm re-reading it. I would hesitantly recommend starting with the first book, but I think this would work just fine as an entry-point.

Post-Pennsic Catch-Up

Aug. 13th, 2017 09:13 pm
[syndicated profile] vikas_vestments_feed

Posted by Victoria Swann

I promise I'm nearly done with this JPG

Another Pennsic survived, and indeed enjoyed (unlike last year's Bataan Death March).  The weather was, on the whole, nearly perfect; we had a marked decrease in camp drama; our small co-prosperity sub-sphere worked together to correct some problems[1]; and I wasn't killing myself trying to get things done to a deadline...which may be why I actually got some things done.  Mind you, it is still rather a drain to be den mother, hall monitor, and assistant principal to 70 variably-situated people, and I am nearly ready to be done with it so I can enjoy my vacation as a free agent, so I'm hoping to train up a padawan to take over in a couple years.  But let's get to the arty stuff.

Stuff worked on/finished/set on fire:
On Wednesdays, we wear pink.
  • Partlet: Much to my joy, I found that Past Me had actually cut one out already.  I sewed it together and hemmed it in the field, and it was ready for my class Saturday morning, along with--
  • Elizabethan working kirtle: you know, the one I cut out last year and finally finished last month?  Was miles too big around my torso, and also the neckline is kind of verkachte.  Fortunately the partlet covered the latter, and my posse pinned the back seams more tightly so I didn't look like a complete goober.  So, there's some fix work to be done in the fall sewing. (I have more thoughts about the cut for a later post.)
  • Linen Gothic Fitted Dress: I finished it before leaving! other than the eyelets and hemming, which I also did in the field.  I'm particularly smug about it because I did the pattern adjustments on my own & on the fly, which is not at all easy, but my eye is clearly getting better at this.  It too is rather too big, but I'm not 100% sure that's wrong for a working dress; something else I shall expand on in a future post.
  • The Pourpoint: I got the new lower sleeves quilted & pinned before leaving, and I showed the beast in the A&S display, in pieces, as a work in progress (wherein I also got to work on it, at least a bit).  Now it's just $*@&# buttonholes all the way down.
  • Linen Trousers Mk. 2: the first time my dashing consort wore them, he split the seam at the back of the crotch gusset.  I hate pants.  Pants are stupid.
learn and fear these arms!
I also finally got to hang the banner I painted a couple months ago, which is another nice smug feeling.  It is rather a bodge job (I tacked some of the messy edging I'd cut away onto the top as fast-and-dirty ties), and it should really have a pole and all; but this worked for the moment (as it was, I only got it hung up on 2nd Monday) and I can improve it later.  

Speaking of improvements, I now have a list of them for our pavilion; most involve textile printing of some kind.  I missed the series of classes that The Subject Matter Expert was holding--not only was I up to my ass in camp foo, but you needed to bring some materials that I didn't have a prayer of getting together in time--but the Printed Textiles in the Middle Ages FB group is full of info and I am hoping to start with something small and not particularly important; namely covers for our camp coolers, because ugh.  When I have some confidence in the technique, I want to print a canvas floor for the pavilion[2], ideally to look like the tiled floors you see in all the 14th c. illuminations.  And on the non-textile front, we're planning to paint the pavilion poles (not in designs, just colors); and I picked up a plain white folding shelf unit to keep the tent's inside a little less of a rubbish tip, and I want to do some designs on that.  Maybe acanthus leaves, maybe armorial bits, we'll see.  

For the fall schedule, I'm keeping some flex in case I'm needed to help with a wedding dress that's set to launch next month; but the general prioritization looks like this:

1a) and the test version, too.  oh god more quilting
2) Do the small bits of mending required post-Pennsic.
3) Knock together a new pouch, as the one I made, guh, ten years ago? more? is crappy and falling apart and was only a kludge to begin with.  
4) *deep breath* Make myself a set of high fashion Gothic fitted dresses; the under-dress of the blue silk I got at Birka a few years ago, and the over-dress out of the silk and gold lampas l I just ordered from Sartor.  I need to make something for myself that isn't an experiment or a kludge job.  ...There might end up being pearls on it.  I'm just sayin'.

I'm not going to look past that point for now, but hovering in the parking lot is the bunch of really nice linen we also ordered from Sartor, because for next Pennsic my dashing consort is getting a full kit of Field Gothic.  Currently figuring a blue tunic and ochre hose, and once those are done I'll see what will go well as a hood (maybe a dark red).  And I do want to make him a full-on Modern Maker fancy 16th c. suit, too.

That'll do for awhile.

[2]  You might think that the next step after that is painting the pavilion itself, but I don't have a strong feeling of what exactly I'd want to do, so Imma let that marinade for awhile

One year of cycling, installment #2

Aug. 13th, 2017 01:25 pm
rbarclay: (rad)
[personal profile] rbarclay
For background look here.

Anyway: 6,092.2km, €0.58/km.

Fiber Maintenance - Newark

Aug. 16th, 2017 06:00 am
[syndicated profile] linode_status_new_feed

Posted by Linode

Aug 16, 06:00 UTC
Completed - The scheduled maintenance has been completed.

Aug 16, 04:01 UTC
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.

Aug 11, 19:02 UTC
Scheduled - On Wednesday, August 16th at 00:00 (GMT-4) we will be performing maintenance on a fiber span from our Newark data center to a remote carrier hotel. During this maintenance, we will be tuning the optical network for increased capacity and resiliency. The maintenance window is scheduled for two hours. This fiber link is redundant, so we do not expect any downtime; However, a brief period of packet loss or increased latency may be observed.

Struck by lightning

Aug. 11th, 2017 07:18 pm
rbarclay: (donald)
[personal profile] rbarclay
No, not me, but one of the trees in our garden. Interestingly enough, not one of the bigger trees around, maybe 3.5m where 30m further there are 20-25m high ones, and just ~7m from the houses lightning rod (6m high).
Fell on one of the in-laws cars, but no discernible damage. Just one electric garden lantern was knocked over.

Secrets management with Docker Swarm

Aug. 6th, 2017 05:34 pm
[syndicated profile] sweharris_feed

One of the big problems with a cloudy environment is in how to allow the application to get the username/password needed to reach a backend service (e.g. a MySQL database). With a normal application the application operate team can inject these credentials at install time, but a cloudy app needs to be able to start/stop/restart/scale without human intervention. This can get worse with containers because these may be started a lot more frequently.

It’s tempting to just put the information into a config file that’s part of the container build, but this has a number of issues, including:

  • The container can be pulled apart and the credentials exposed
  • The config file may be checked into source control
  • Passwords may change; you don’t want to rebuild and redeploy each time

The 12 Factor approach is to have credentials passed in via the environment (typically an environment variable). Docker secrets is the model that Docker Swarm Mode uses to achieve this.

Note: this doesn’t work with standalone Docker, nor with containers not started as part of a service. It will work with a single-host swarm and a scale 1 service, though.

What is a secret?

A secret, in Docker, is pretty much any string of text. This means you could put pretty much anything into it; a JSON file, an SSL certificate, API keys, a password… anything. The limit is around 500K, which should be large enough!

This is stored in the Docker Swarm raft log, which means it’s replicated across all the management nodes for resiliency. It’s also (since Docker 1.13) encrypted, which means the secrets are never stored in plain text on any disk.

Creating a secret

This is pretty straight forward. You can specify a file that has the secret, or use - to mean STDIN.

% echo hello | docker secret create my-secret

% docker secret ls
ID                          NAME                CREATED             UPDATED
aqfet0saziaqzspvih6p6w72n   my-secret           13 seconds ago      13 seconds ago

% docker secret inspect my-secret
        "ID": "aqfet0saziaqzspvih6p6w72n",
        "Version": {
            "Index": 893
        "CreatedAt": "2017-08-06T21:53:38.771368641Z",
        "UpdatedAt": "2017-08-06T21:53:38.771368641Z",
        "Spec": {
            "Name": "my-secret",
            "Labels": {}

That’s all there is!

Using secrets

We can create a service that refers to the secret. This will then appear in /run inside the container

% docker service create --detach=true --name secret-service \
         --secret my-secret --entrypoint /bin/sh --tty=true centos

% docker service ps secret-service
ID                  NAME                IMAGE               NODE                   DESIRED STATE       CURRENT STATE                    ERROR               PORTS
kv3uo8qm95h3        secret-service.1    centos:latest   Running             Running less than a second ago

% docker exec -it secret-service.1.kv3uo8qm95h3anox5q372pojh /bin/sh
sh-4.2# ls /run/secrets
sh-4.2# cat /run/secrets/my-secret

Note that /run is a tmpfs filesystem and so the secret still doesn’t appear on disk; it’s only stored in memory.

Using secrets with a stack

Because a stack can have private namespaces as well as using the global one we have to define this as an external resource. The model looks very similar to what we’ve seen for networks. That’s deliberate.

% cat secret_stack.yml
version: '3.1'

    image: centos
      replicas: 1
    entrypoint: /bin/sh
    stdin_open: true
    tty: true
      - source: my-secret

    external: true

% docker stack deploy -c secret_stack.yml secret-stack
Creating network secret-stack_default
Creating service secret-stack_os

% docker service ps secret-stack
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
eh1ta48g3gfy        secret-stack_os.1   centos:latest    Running             Running 17 seconds ago

% ssh test2 docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
2e17c5b3a50a        centos:latest       "/bin/sh"           31 seconds ago      Up 30 seconds                           secret-stack_os.1.eh1ta48g3gfyduvgxxx7f0uev

% ssh test2 docker exec secret-stack_os.1.eh1ta48g3gfyduvgxxx7f0uev cat /run/secrets/my-secret

Updating secrets

This is where we start to hit limits. A secret, once in use, can not be changed or even removed. There’s not even a docker secret update option, and docker secret rm fails…

% docker secret

Usage:  docker secret COMMAND

Manage Docker secrets

      --help   Print usage

  create      Create a secret from a file or STDIN as content
  inspect     Display detailed information on one or more secrets
  ls          List secrets
  rm          Remove one or more secrets

Run 'docker secret COMMAND --help' for more information on a command.

% docker secret rm my-secret
Error response from daemon: rpc error: code = 3 desc = secret 'my-secret' is in use by the following services: secret-service, secret-stack_os

This may be a bit of a problem; if you have placed an SSL cert into the secret store and it now needs to be updated then how can you do this?

We have to cheat a little. We can create a new secret and then update the service(s) to use this new secret but under the old name:

% echo A new secret | docker secret create my-secret.v2

% docker service update --secret-rm my-secret --detach=true \
        --secret-add source=my-secret.v2,target=my-secret secret-service

% docker service ps secret-service
ID                  NAME                   IMAGE               NODE                   DESIRED STATE       CURRENT STATE            ERROR               PORTS
4hf3m0rwroeh        secret-service.1       centos:latest   Ready               Ready 9 seconds ago
kv3uo8qm95h3         \_ secret-service.1   centos:latest   Shutdown            Running 11 seconds ago

% docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
7ac269ffb300        centos:latest       "/bin/sh"           35 seconds ago      Up 21 seconds                           secret-service.1.4hf3m0rwroehf57evqdowmbsz

% docker exec -it secret-service.1.4hf3m0rwroehf57evqdowmbsz cat /run/secrets/my-secret
A new secret

That’s messy; the docker service update command causes the service to be restarted. In theory that shouldn’t cause downtime to your app, but it’s still a restart and any internal state will be lost.

We also need to update every service that uses a secret before we can remove the old secret

% docker service update --secret-rm my-secret --detach=true \
        --secret-add source=my-secret.v2,target=my-secret secret-stack_os

% docker secret rm my-secret

% docker secret ls
ID                          NAME                CREATED             UPDATED
kolmhlqxh8wsle75j4siv6dl8   my-secret.v2        6 minutes ago       6 minutes ago

Using secrets as a “seed”

Docker secrets enable us to use an external password vault (e.g. Hashivault). The secret stored inside the Swarm would be sufficient to let your application log into the vault and then get the password it needs (e.g. for the database). It could be used to talk to an API to generate and retrieve an SSL certificate, with the management happening at the enterprise system (e.g. renewal; next time your container starts it will automatically get the new cert).

These “seed” credentials still need to be controlled because they provide access to the final system, but it allows for greater flexibility, especially where credentials may be short lived (Hashivault can generate short-lived passwords in the database; Lets Encrypt certs live 90 days

Related: Docker configuration items

Since Docker 17.06 there is also docker config. These work conceptually in a similar way to secrets but are implemented slightly differently at the backend; in particular they’re not encrypted at rest and they’re mounted directly into the container.

Management of configs (and the limitations in rotation) are very similar to secrets, just using the docker config command.

Docker configs can work with secrets; e.g. you could create a web server where the config and the HTML index file come from config entries and the SSL certificate comes from the secret entry.


Docker secrets are currently very limited in what they can do. In particular rotation and updating of secrets is painful and requires your service to be redeployed.

However they do provide a way of handling the “how to get secrets into a container”, which is a hard problem to solve without technology like this.

Using them as a “seed” to access a fully fledged secrets solution (eg a Vault or a Cert management system) overcomes many of the limitations and allows enterprise scale secret management.

Note, however, that anyone in the docker group can get the plain text! This is yet another reason to treat all access to these servers as highly privileged.

[ bookmonth ] 2017-07

Aug. 6th, 2017 06:11 am
vatine: books-related stuff (books)
[personal profile] vatine
Book list )

I am starting to think I am getting a pile-up of entries to write, again. Anyway, if we take linear extrapolation to year's end, we get just shy of 132 books, which is what June's extrapolation pointed to. This sounds plausible, but...
Page generated Aug. 18th, 2017 03:14 am
Powered by Dreamwidth Studios