Minecraft is a land of Cubes. And yet, in this blockland, it turns out the circle is a very powerful tool. Using the basics of trigonometry, we can build all sorts of things.
Continue reading
Circles in Minecraft?
3
Minecraft X Y Z
Minecraft uses the Cartesian coordinate system to locate and display blocks. That means that every block location in a Minecraft universe can be described using three values: X, Y, and Z. Even the player’s avatar “Steve” has a position recorded this way. If you type the F3 key, you can see a bunch of text on the screen. Buried in there somewhere are the 3 values for Steve’s position.
Securing the Cyrus SASL Sample Server and Client with Kerberos
Since running the Cyrus SASL sample server and client was not too bad, I figured I would see what happened when I tried to secure it using Kerberos.
Continue reading
Running the Cyrus SASL Sample Server and Client
When I start working on a new project, I usually start by writing a “Hello, World” program and going step by step from there. When trying to learn Cyrus SASL, I found I needed to something comparable, that showed both the client and server side of the connection. While the end state of using SASL should be communication that is both authenticated and encrypted, to start, I just wanted to see the protocol in action, using clear text and no authentication.
Translating Between RHOS and upstream releases Redux
I posted this once before, but we’ve moved on a bit since then. So, an update.
#!/usr/bin/python upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex (Tag 2012.1)', 'Folsom (Tag 2012.2)', 'Grizzly (Tag 2013.1)', 'Havana (Tag 2013.2) ', 'Icehouse (Tag 2014.1) ', 'Juno (Tag 2014.2) ', 'Kilo (Tag 2015.1) ', 'Liberty', 'Mitaka', 'Newton', 'Ocata', 'Pike', 'Queens', 'R', 'S'] for v in range(0, len(upstream) - 3): print "RHOS Version %s = upstream %s" % (v, upstream[v + 3])
RHOS Version 0 = upstream Diablo
RHOS Version 1 = upstream Essex (Tag 2012.1)
RHOS Version 2 = upstream Folsom (Tag 2012.2)
RHOS Version 3 = upstream Grizzly (Tag 2013.1)
RHOS Version 4 = upstream Havana (Tag 2013.2)
RHOS Version 5 = upstream Icehouse (Tag 2014.1)
RHOS Version 6 = upstream Juno (Tag 2014.2)
RHOS Version 7 = upstream Kilo (Tag 2015.1)
RHOS Version 8 = upstream Liberty
RHOS Version 9 = upstream Mitaka
RHOS Version 10 = upstream Newton
RHOS Version 11 = upstream Ocata
RHOS Version 12 = upstream Pike
RHOS Version 13 = upstream Queens
RHOS Version 14 = upstream Rocky
RHOS Version 15 = upstream S
Tags in the Git repos are a little different.
- For Essex though Kilo, the releases are tagged based on their code names
- 2011 was weird. We don’t talk about that.
- From 2012 through 2015, the release tags are based on the date of the release. Year, the release number. So the first release in 2012 is 2012.1. Thus 2012.3 does not exist. Which is why we don’t talk about 2011.3.
- From Liberty/8 the upstream 8 matches the RDO and RHOS version 8. Subnumbers are for stable releases, and may not match the downstream releases; Once things go stable, it is a downstream decision when to sync. Thus, we have tags that start with 8,9, and 10 mapping to Liberty, Mitaka, and Newton.
- When Ocata is cut, we’ll go to 11, leading to lots of Spinal Tap references
Importing a Public SSH Key
Rex was setting up a server and wanted some help. His hosting provider had set him up with a username and password for authentication. He wanted me to log in to the machine under his account to help out. I didn’t want him to have to give me his password. Rex is a smart guy, but he is not a Linux user. He is certainly not a system administrator. The system was CentOS. The process was far more difficult to walk
Distinct RBAC Policy Rules
The ever elusive bug 968696 is still out there, due, in no small part, to the distributed nature of the policy mechanism. One Question I asked myself as I chased this beastie is “how many distinct policy rules do we actually have to implement?” This is an interesting question because, if we can an automated way to answer that question, it can lead to an automated way to transforming the policy rules themselves, and thus getting to a more unified approach to policy.
Continue reading
Mirroring Keystone Delegations in FreeIPA/389DS
This is more musing than a practical design.
Most application servers have a means to query LDAP for the authorization information for a user. This is separate from, and follows after, authentication which may be using one of multiple mechanism, possibly not even querying LDAP (although that would be strange).
And there are other mechanisms (SAML2, SSSD+mod_lookup_identity) that can, also, provide the authorization attributes.
Continue reading
Hierarchy of Isolation
One way to understand threads, process, containers, and VMs is to look at what each level of abstraction provides for isolation.
Continue reading
Getting the URLs out of the Service Catalog with jq
When you make a call to Keystone to get a token, you also get back the service catalog. While many of my scripts have used the $OS_AUTH_URL to make follow on calls, if the calls are administrative in nature, you should use the URL in service catalog.
This makes use of curl fetch the token and jq to parse the output.
Continue reading