July 30, 2007
While getting lunch today I walked past a woman talking on her phone. She was speaking in a language I could not identify – this is odd enough b/c I’m normally pretty good at picking out what language it is even if I can’t understand it. What was odder still was that I distinctly understood the words ‘manolo blahniks’ in her conversation.
July 29, 2007
completely unrelated to anything:
The song “Dont Change your Plans” By Ben Folds Five: I have an extremely strong memory of listening to this song while walking cori (my dog). It was in my old apartment. It was probably Fall of 2000 or 2001? It had to be Fall b/c I remember being dressed warmly and thinking how similar the lines “the leaves are falling back east” were to how it was at the time. I also remember walking cori in the dark – so I figure sometime after the time-change when it gets dark earlier.
This song came up tonight on random play and it made me a bit .. I dunno – nostalgic isn’t the right word. maybe wistful. I remember feeling in rather dark moods at that time. My music selection at the time trended toward vaguely depressing music which kept me in the right state of mind I needed to do my work. To further date this experience – I was listening to all of this on my minidisc player. Yah, I was one of the 3 people who bought those.
Anyway – hearing the song brought back that memory rather intensely. Despite my relative state of mind at that time that memory is somehow pleasant for me. Odd. It’s probably just my general attraction to the Autumn months.
“You have made me smile again in fact, I might be sore from it”
July 25, 2007
I setup the bits to make git the scm format for yum-devel. setting it up wasn’t all that difficult, actually. The hard part now is adapting my work flow to work with this.
Here are the set of things I need to do w/an scm:
check out HEAD from my scm. modify files locally. check in changes and have them be available to all other developers. Dealing with conflicts and merges along the way.
I can do this now with git as it’s been setup. (git pull, git commit -a, git push)
as we move to a new development cycle in yum I need to be able to take the latest HEAD, make a branch of it to become yum-3.2.X (for example) and diverge from there. So that I can commit new dangerous stuff to HEAD and only put backports and fixes into the yum-3.2.X branch. I do this by making a new sandbox dir for my 3.2.X branch so I can cd into that dir, fire up an editor and work w/o wondering what branch I’m in.
I can _mostly_ do this now in git. the pushing and pulling from branch to branch and getting the changes to the non-HEAD branch is excruciatingly arcane set of commands, but I think it works, sorta.
From any given branch (HEAD or one of the maintenance branches) I need to create an arbitrary tag which specifies the files in a specific version of yum: re: yum-3-2-3 on the yum-3-2-X branch. or yum-5-0-0 on the yum-HEAD branch. Then with those tags I need to be able to check out a tag like this from my build script, make a tarball and build from there.
I can list the tags, I’m not _really_ sure how to make the tags and if the tags are per-branch or are independent of the branch.
I want to generate a changelog from commit comments in just this branch, nothing else.
No clue if the log command in git obeys what branch you’re currently on or not. This was one of the things in cvs that always felt odd.
So that is ALL of the features that I require out of an SCM and that is how I do things. Any suggestions on what I should be doing to make the above more obvious to me and to any future contributor?
What I’ve noticed so far is that every time I want to do anything in git I have to be remarkably verbose about what I want. So if I’ve made a new clone and I set the branch to be a local track of some branch remotely, I expect that when I make changes and want to push them that I don’t need to tell it the branch I want to put them in, again. Since it knows where the branch I want to use is when I run ‘git pull’ I would expect it could use that same path for ‘git push’. Tonight I discovered that it can – but only if the local copy of the branch and the remote copy of the branch have the same name. It doesn’t just keep track of it on its own. Even though it is already in the metadata. I’ve played with git enough now to know that I can probably force it to work but it won’t feel all that sane for a while.
Toshio and Warren helped me figure out how to do something similar to that in bzr_ng tonight. The interface to bzr is far and away less painful than git’s. But since a lot of things in fedora sure seem like they’re leaning in the direction of git (most importantly to me fedora-admin scm) I’m trying to learn git as much as possible but as I said today on my email about the yum git repositories:
I don’t work on yum to be good at using git. Nor did I work on yum to be good at using cvs or svn or bzr or hg. They are just means to an end. If I find I’m spending a lot of time screwing around fighting with git (I’m going to exclude this week b/c that’s ALL I’ve done this week) we may see this distributed-scm-experiment come to a shrieking and sudden halt.
July 23, 2007
I’m not going to comment about my predictions, yet, b/c I don’t want to spoil anything for anyone. Eunice and I finished it on Saturday evening and I liked the way it was done. It closed out well, I don’t feel any longing about any unanswered questions. My only problem is a sense of regret. It’s over and it is not going on from here.
For the last 7 years or so since I discovered this series of books (I only started reading them about the time book 3 came out) I’ve almost always been waiting for the next book. It was nice to know we were going to hear more about these characters. Therefore, I’m a little sad that is gone.
July 18, 2007
I started to play with rsyslog b/c the decision was made for fedora 8 to go with rsyslog instead of syslog-ng. One of the reasons for this is that rsyslog maintains backward compatibility with the old-style sysklogd syslog.conf format. This file has been in that format since the dawn of time and many would rather it was left alone (despite the format being god-awful). Anyway – let’s talk about rsyslog
rsyslog has a bunch of good features:
1. supports multiple listening ports and destinations – udp and tcp
2. with stunnel it supports encrypted log sending
3. it can take interesting options to put files in new and exciting places.
$template hostsecure, “/var/log/hosts/%HOSTNAME%/secure/%$NOW%”
for anything coming in on facility authpriv – put it in a subdir which maps to something like:
In short, that’s the major feature I need to implement rsyslog in the same way I’ve used syslog-ng. With the above configuration you don’t need a logrotater you can just run:
tmpwatch -f 720 /var/log/hosts
and that will purget all files older than 30 days, automatically. No need to stop the daemon, no need to move files around.
Problems I encountered:
1. some of the features I needed weren’t there at first – for example it didn’t automatically make subdirs for the logs it was making – therefore having a separate dir per host was trickier than it needed to be. Luckily the maintainer was willing to add that in so it’s now available in 1.17.0 and above
2. the config file is not the most obvious. In order to maintain compat with the old format the additional configuration options are a bit ‘hurky’ feeling. a $ precedes all of them which ends up looking like very scary perl with CamelCase. I made a couple of suggestions on maybe a way around this problem but it’s not the end of the world if it doesn’t happen. For example
will log all logs to host: hostname on TCP port 1514
will log all logs to host: hostname on UDP port 1514
that feels like a bit of hack to keep compat with the old format.
3. the docs seem to focus on a usage case about which I am less familiar. I tend to use specialized log daemons when I need to:
a. log across a wan, using encryption
b. setup a central log host and need the logs to be sensible
c. need to use SEC or something like it make things behave.
As I refine the config file we’ll use in fedora and elsewhere I’ll update it here:
All in all I think rsyslog is going to be capable. If the config file format changes or is improved with some more obvious examples (and I’ll help with the ones I can) then I think it’ll be good for central log hosts. The maintainer is active and responsive, not to mention helpful. I’ll update more here as I have it.
July 15, 2007
So, I’m going to write these down now – so that when I’m right then I have some evidence I was right and I can point and mock at others about how right I truly was (muahahah). And if I’m wrong you can expect this post to be deleted without any evidence it ever existed 😉
Predictions for Harry Potter book 7:
1. Snape is a good guy (more or less)
2. Snape was in love with Lily Potter (and she had a soft spot for him, too). This is why Voldemort didn’t want to kill Lily and this is why Snape turned against him. This is also why Dumbledore believed Snape. Dumbledore’s a sucker for people who are acting out of love.
3. There was someone else in the Potter’s house the night Voldemort killed Lily and James. We know this b/c: for some reason Dumbledore had James’ invisibility cloak and gave it to Harry in book One. Also, we have way a lot of detail of that night, of what went on inside the house. I think it was Snape under the invisibility cloak, actually. And I think the parallels b/t Snape at Godric’s Hollow and Harry on top of the tower when Dumbledore died are going to be strong. I’m a little less confident of this but it may be that James froze Snape under the cloak to keep his cover and to keep him alive. James saving Snape twice and in this case where he though he might have been able to save Lily would continue to account for his hatred for James.
4. As Eunice mentioned last night – we seem to know nada about the Potter-side of Harry’s family. I’m betting his lineage will get explained a bit and it’ll be very, very gryffindor .
So, we’ll find out how right I am in just over 5 days.
July 13, 2007
fedorapeople.org is coming together and we’re readying for a launch $soon.
Today I got to play with poly instantiated tmpdirs. On the advice of Jeremy I talked to Dan Walsh b/c he is the knower of many security-related things. He told me to look at the pam_namespace docs . That brought me to a fairly obvious textfile. 🙂
Users live in /home/fedora which is a bindmount of /srv/home (for quota reasons, etc)
I setup pam_namespace.so in my pam.d/system-auth file like so:
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session required pam_namespace.so
Then I edited my /etc/security/namespace.conf file to read:
/tmp /srv/polyinst/tmp/ user root,adm,apache,puppet,nagios,rpm /var/tmp /srv/polyinst/vartmp/ user root,adm,apache,puppet,nagios,rpm
Next I made the dirs: mkdir -p /srv/polyinst/tmp /srv/polyinst/vartmp
and as the docs said: chmod 000 /srv/polyinst/*
now I rebooted for good measure and logged in.
If I log in as root I see /tmp in /tmp where it lives
If I log in as me I see /tmp with nothing but my ssh tmpfiles in it. I make a few dirs in there to be sure.
Then I logout as me, log back in as me – the files are still there – that’s pretty good.
Then I logout as me, get someone else to log in as not-root and hunt for my dir. No joy.
So, this is all good. But it gets better. Since I put tmpdirs on the same logical device as the homedirs are on then that means I get quota’d tmpdirs for free. The quota I set on /srv (where /home is) applies to /srv/polyinst/*, too. So, we’re safe on quotas.
Users can still get to each other’s homedirs if they are so unprotected but tmpdirs don’t cause unlimited pain.
Now all I need is to get a nice tmpreaper job to traverse those paths and clean them up every now and then.
Thanks to Jeremy and Dan for the pointers. And thanks to planet fedora for first introducing me to the idea of polyinstantiated dirs.