Return Of The SELinux Security Contexts
I wrote my own SELinux policy file today!
Today I realised my CGI pages weren't coming up because the scripts weren't allowed to connect to, read and write the Postgres socket. (They also seem to require the ability to getattr and read the krb5.conf file, and I have absolutely no freaking clue why, because my code doesn't use Kerberos in any way). I'd done a bit of research and found the command:
grep <error messages> /var/log/messages | audit2allow
A bit of questioning on #selinux on irc.freenode.org revealed that if I did audit2allow -M <name>, I'd get a module with the name I gave, so that later I can identify what particular policy modules I've loaded into SELinux and what they do (rather than just 'local'). (They even have version numbers too!) The module .te file is a text file, so you can edit it. Including all the various permissions you want to set in one file means that when you compile and load it with:
checkmodule -m -M -o <name>.mod <name>.te
semodule_package -o <name>.pp -m <name>.mod
semodule -i <name>.pp
(which the audit2allow script will do all but the last automatically) then you can have all your policy revisions in one neat place, rather than grabbing each separate error, making a separate policy for, and then probably overwriting the last policy module you called 'local' or whatever.
Neat.
Now all I have to learn is how to create new SELinux types, so I can say "only
these HTTP scripts are allowed to read and write to this directory". Then I
will truly know what the hell I'm doing. Possibly.
posted at: 17:28 | path: /tech/fedora | permanent link to this entry
The Dance Caller's Gadget
I, as some people may have noticed, teach
Irish
Set
Dance
1 - er,
Dance. To do this without
developing a
voice
that can kill at ten paces, I bought a
PA
system with a built-in wireless microphone, CD player,
echo (!) and can run
off its own internal batteries, which, when combined with my
music player,
means that I can go pretty much
anywhere
2 to do a dance.
Of course, the Karma is plugged in via line-in, and it doesn't have a remote control, so I have to race back to the player to turn it off, all the while avoiding getting too close to the speaker to set up a quick bout of ear-pulverising feedback. I've got a belt-pack and somewhat uncomfortable headset to wear, which has some niggling internal fault that causes its gain control to not work, meaning that 2.11 on the dial on the back of the PA system is too soft to hear, and 2.13 is dangerously loud. I also occasionally have to carry around an index card with the notes for the dance on it, due to Irish Set Dance's one consistency: there's no rule about how a particular movement is done that isn't broken by at least one historical set. (Occasionally I even have to refer back to the book because something isn't quite clear in my notes, and sometimes even the book doesn't clarify it perfectly...). If I had a remote control, that'd be another thing to carry.
A while ago I started work on the Irish Set Dancing Markup Language, my "what's a DTD?" attempt at writing a XML specification for encoding set dance notes. (As an aside, here, I think that Irish Set Dancing and American Contra are the two forms of dancing that programmers and techies grok best: they involve keywords that code for a set of specific, usually standardised movements, they have recursive and iterative structure, and you almost always get to dance with members of the opposite sex.) The idea was that, with an appropriate browser on a palm computer, you could get the entire instructions for a dance in a modest size; and you could increase or decrease the complexity using some simple controls. You might have "{A&R, HHW}x2", but at the click of a button it turns into "Advance and Retire (in waltz hold) once, then House Half Way (in waltz hold), and repeat those two to get back to place". Sometimes all you need for the same instruction is "Slides". The ISDML was to try and give a short description at each level, so that each subgroup would have an abstract when 'rolled up'. If someone better at speaking XML and with time on their hands could email me, then I'd appreciate it.
And now that palm computers can play standard media files like mp3s (and possibly oggs), we can start to construct a palm device that can act as a reminder card and a music controller. I think what I need next is a bluetooth audio interface - a bluetooth device that provides an audio plug (two RCA sockets, a 1/4" jack, a 1/8" stereo jack, whatever), so that the palm computer can send its audio across the room wirelessly to my PA system. If the palm computer could also simultaneously have a connection to a bluetooth phone headset - i.e. a wireless microphone - then I'd throw all the other stuff away. Hell, half of this my Nokia 6230i (link not shown because it requires MacroDictator Flash 8) could do.
I'd be willing to pay $1000 for software that could do all this, and would open source it with whatever license you want. Anyone interested?
1: While 'Safe For Work', this picture may cause involuntary vomiting and the uncontrollable desire to poke ones eyes out. Be careful. And don't ask why all eight men in the set are dressed up as women. It's safer not to know.
2: A set dance weekend away camp at Katoomba YHA, where I'm
told that they have a big wooden floor just right for doing set dancing
on? Why, whatever made you think of that idea?
posted at: 17:28 | path: /tech/ideas | permanent link to this entry
I have a sudden craving for purple rackmount cases...
In wandering around looking for where to submit a bug about CFS to, I
stumbled across the pages of
Spinserver. No, it's not a
daemon to allow you to run spin locks faster; these are rackmount cases
where the 'back' of the motherboard - the bit with all the ports on it -
are at the front. Despite it flying in the face of tradition, there's a
lot to recommend this configuration:
For a start, it's a lot cooler. With the back being almost entirely comprised of large fans, you can move serious amounts of air through these cases. The 3RU cases can get up to 3 cubic metres of air per second - something I have a hard time just imagining. And, because the only cable at the back is the power cable, most of the clutter that slows air down back there is eliminated. You can even put the entire rack unit against a wall, or back to back with another, since you pretty much don't need access to the back for anything short of complete disaster.
Since all the cabling is at the front, you can do all your patching in one place. That's where the ports on your network switch are, right? You can even get rid of KVM switches by simply plugging the head monitor, keyboard and mouse cables in directly, saving a lot of extra clutter and making it bleeding obvious which machine you're working on. You get all the diagnostic lights at the front, too, so it's much more obvious when a cable isn't plugged in quite right.
And to cap it all off they're made from top-quality components right
here in Australia. I want one so badly now! I wonder if they do a
2RU case that'll take two Via EPIA motherboards side-by-side...
posted at: 17:28 | path: /tech | permanent link to this entry
How not to install Fedora Core 5
I wanted to reinstall the operating system on my server. After my totally
newbie install of Fedora Core 2 test 3, then using the development and
bleeding-edge repositories and adgering the Python system (including
up2date), and then using atrpms with innocent glee until I found out that
they had a totally different and even nastier version of 'bleeding edge',
the whole system felt as if it had been limping along being delicately
prodded to stay upright. The final straw was the
attack
on another machine in the lab which, while it didn't
seem to have actually broken into my machine, still didn't give
me the Ring Of Confidence.
But here's how not to do an install of Fedora Core 5:
On the plus side, I learnt a few things:
Control - Interaction Versus Specification
I realised, in bed last night, that there's a spectrum of control that runs from
the immediate to the delayed and detached. The more detached we are from what
we're trying to control, the more we have to specify exactly how we want the result
to come out; the more interactive our control, the more we can fine-tune it on the
spot to be how we want.
(This came out after having shown Kate the "How to shoot yourself in the foot in various programming languages" page, in particular noting the 370 JCL one: "You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.", which relies less on the physical details of 370 JCL and more on the environment it was written in: old-style MIS bureaus where computers were attended by chanting acolytes and high priests in formal robes, and if you'd been really good you could even see a photo of a computer almost like the one you had in the sealed room doing work for someone else. Of course, now with everyone having a computer on their desks that leaves an IBM 370/135 for dead (240,000 bytes of memory! Count them!), you can interactively scale that graph to the size you want, rather than having to specify exactly how big every single element would be in a 4,000 page document. And that's where the realisation came from.)
One key thing, to my mind, is that Open Source has given us part of that interactivity. If you're a user with no programming ability, you have to specify how things should look and how things should work. If you have access to the source code and the programming ability to change it, all of a sudden you can interactively change the code to do what you want. The process of getting that algorithm to do the right thing, or the output to come out the way you like it, is suddenly much much faster.
And then because a lot of developers are on email lists, IRC channels and web forums, things can often be fixed much faster. Not only can the developers come to an agreement about how a thing should look quickly, but suddenly that forum post, email archive or channel log has become a 'standards document' that people can refer to at a later time. And, furthermore, they can communicate with the users much more quickly - the users have a slightly more 'interactive' experience in getting their particular bug fixed or feature implemented. With the closed business model that closed source is often associated with, the user has much less influence and a much longer delay before they see something being done; so they have to specify much more.
And, personally, I think specifications can lead developers down the wrong path. If there's something that doesn't quite make sense in the spec, then the smart developers have to go back to the client and get it cleared up; the dumb developers implement it in whatever way they think it should be done (or whatever way is easiest) and then the client inevitably says "No, that's not how we want it," and you have another round of specification-writing. Standards are good, and specifications are essential when you're wanting many people to work on a project (perhaps over a long period of time). But the more disconnected the end user is from whatever's being written, the more time is wasted writing specifications that only serve to insulate the programmer from any form of interactive decision-making, the longer it takes and the more it costs and the more lawsuits you end up with when things don't work quite as the user wishes.
(Users are a fickle bunch, too, and by the time a spec is implemented the user may have changed their mind. Which leaves the user with something that they don't want but agreed to pay for. Which is no solution at all, really.)
Look at Cricket or Tennis: umpires and linesmen and cameras and watchers all trying to make sure that the specifications don't get broken, and causing lots of upset and angst when the decision they make doesn't seem to be fair according to a different interpretation of the rules. Look at Ultimate Frisbee: no referees, and the players interactively agree about what's fair and not (inside the global specifications that govern all Ultimate Frisbee games everywhere.) Look at Calvinball: only one rule and lots of fun for its participants who interactively agree on how to play, but you can't write it down because codifying it is useless by definition. Is competition Cricket fun for its players or umpires? (Could someone even argue that they're not out there to have fun, they're being paid to do a job with their skills?)
Imagine a society like the Edenists in Peter Hamilton's "Night's Dawn" trilogy: people that have an inbuilt biological 'affinity' connection. They can 'telepathically' communicate with eachother, but they can also join a superconsciousness called Consensus that combines the thoughts and feelings of the entire population. If some new decision needs to be made, the society communicates interactively and comes to a consensus (hence the name) - some people might have a differing opinion about what the decision should be, but they are in the minority and can still see that the group knows their point of view and has chosen using all their intellects and feelings, rather than a small minority.
Now that's interactive!
posted at: 13:19 | path: /society | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.
You can also read this blog as a syndicated RSS feed.