For those who haven’t heard through Flock or the rumor mill, today is my last day at Red Hat and also the beginning of a hiatus from working on Fedora. Since I’ve been asked this many times in the past few weeks, this is because I’ve become a bit burnt out having worked on Fedora as both my day job and my hobby for the past seven years. It’s time for me to pull back, let fresh faces fill the roles I held, and do something else for a while to add some spice and variety. I may come back to Fedora or to Red Hat in the future but at the moment I’m only looking far enough ahead to see that I need to go forth and have some new experiences.
I do want to say thank you to all the wonderful people who have worked not just to make the Fedora distribution a solid piece of software but also filled Fedora with friendly faces and kind words. Truly, although I’m physically far removed from the rest of you, you are my neighbors, my community, and my friends. Even though I’m stepping away from working on Fedora, I hope to keep in touch with you via IRC for many many years.
I’d also like to announce that I woke up this morning to find that I’d been made the gatekeeper for a new Fedora Badge. As the badge submitter describes it:
I dream of a future where Toshio could fully express his techniques with the complicity and trust of many dance partners, responding to his moves and being pushed forward by him in the arts of dancing; exchanging, learning, growing as a vibrant community.
Taking away the specifics of dancing and myself, this is my hope for everyone who participates in Fedora: to be able to grow in sympathy with a larger community.
With that in mind, if we’ve danced together and you would like this badge, please contact me (abadger1999 on IRC, toshio.fedoraproject.org via email). I can’t remember everyone’s FAS usernames but I’m extremely happy to award you the badge if you remind me what of what it is :-)
Just installed a new system and was having ssh connections timeout. Then I remembered talking about this same issue last year on IRC. The anecdote is amusing so I figured I would post the logs:
[Mon April 22 2013] * abadger1999 wishes he knew why his ssh connections to infra keep on hanging.
[Mon April 22 2013] <abadger1999> it’s a timeout of some sort… I just don’t know what.
[Mon April 22 2013] <skvidal> abadger1999: did you reinstall recently?
[Mon April 22 2013] <abadger1999> skvidal: nope
[Mon April 22 2013] <abadger1999> skvidal: would that help?
[Mon April 22 2013] * abadger1999 still on f17
[Mon April 22 2013] <skvidal> I have found I often need to set
[Mon April 22 2013] <skvidal> net.ipv4.tcp_keepalive_time = 300
[Mon April 22 2013] <skvidal> in /etc/sysctl.conf
[Mon April 22 2013] <skvidal> to not get timeouts
[Mon April 22 2013] <abadger1999> Thanks. I’ll try that .
[Wed April 24 2013] <abadger1999> skvidal: btw, your sysctl recipe seems to have fixd my ssh timeout issues. Thanks!
[Wed April 24 2013] <skvidal> abadger1999: :)
[Wed April 24 2013] <skvidal> abadger1999: last time it happened to me I had to google for the solution
[Wed April 24 2013] <skvidal> abadger1999: and I found a post from myself from 5yrs earlier
[Wed April 24 2013] <skvidal> abadger1999: _that_ is kinda freaky
[Wed April 24 2013] <pingou> isn’t that what blog are for? :)
[Wed April 24 2013] <dwa> nice
[Wed April 24 2013] <abadger1999> Cool :-)
[Wed April 24 2013] <skvidal> “wow, this dude knew what was going on…. but he sure writes like he’s an ass”
[Wed April 24 2013] <skvidal> “oh….. wait”
Seth, you were more of a teddy bear than an ass.
Mostly posting this to remind myself of the fix the next time I run into this but htis might help some other people as well.
Every once in a while I’ll be working on a git repo in the fedora packages repository and when I
git commit -a it, I’ll end up with an empty commit and the files with changes aren’t actually committed. Other intuitive variations of this like
git add FILE && git commit have the same buggy behaviour.
The reason this is occurring has something to do with the GitPython library which is used by fedpkg to add some changes to your clone of the git repo when you add new source files. It’s somehow changing the index in a way that causes this behaviour. To get out of this there’s a few simple but non-intuitive things you can try:
git reset FILE && git add FILE
git stash && git stash pop
After running one of those pairs of commands you should once more be able to
git commit -a.
Details in this GitPython bug report
Over a year ago I mentioned that the code that rsync needed in order to start using vanilla zlib was finally on its way to being merged. And today, we’ve finally built an rsync package that completes that saga.
All packed up and waiting for my plane to Raleigh. Going there to work on enabling two-factor authentication for the hosts that give shell access inside of Fedora’s Infrastructure. For the first round, I think we’re planning on going for simple and minimal to show what we can do. Briefly, the simplest and minimalist is:
* Server to verify a one time password (we already have one for yubikeys)
* CGI to take a username, password, and otp to verify in fas and the otp server
* pam module for sudo that verifies the user via the cgi
* database to store the secret keys for the otp generation and associate them with the fas username
We’re hoping to go a little beyond the minimal at the FAD:
* Have a web frontend to configure the secret keys that are stored for an account.
* Presently we’re thinking that this is a FAS frontend but we may end up re-evaluating this depending on what we decide to do for web apps and what to require for changing an auth source.
* Allow both yubikey and google-authenticator as otp
I’m also hoping that since we’ll have most of the sysadmin side of infrastructure present that we’ll get a chance to discuss and write down a few OTP policies for the future:
* Do we want to make two-factor optional for some people and required for others?
* How many auth sources do we require in order to change a separate auth source (email address, password, secret for otp generation, phone number, gpg key, etc)?
If we manage to get through all of that work, there’s a few other things we could work on as well:
* Design and implement OTP for our web apps
Congratulations and many thanks to everyone who was involved in the effort to unbundle zlib from rsync! Looks like this long standing bug that’s been a sore spot for many distributions is finally being addressed. It almost makes me want to create a Fedora 18 Feature page for it :-)
This is something I’ve been noticing for a while and am finally getting around to blogging.
In the first days of FESCo, Thorsten Leemhuis was the chairman. One of the quirks of his time was that we’d encounter a topic where we voted on a solution and found that a majority agreed with one sentiment but it wasn’t unanimous. When that happened, Thorsten would be sure to ask if there was anything we could do to make the solution more acceptable to the dissenters even if they still wouldn’t vote for the proposal.
This sometimes lead to discussions of a proposal that had been approved with margins like 7 to 2 and after the discussion and changes, the vote was still 7 to 2. So from an external standpoint, this might be seen as unproductive. Why don’t we just get a decision made and move on?
But over the years I’ve watched a lot of other split decisions be made on several committees from both the inside and the outside and it’s struck me that, perhaps, we don’t do nearly enough of this sort of examination. Making changes after it was clear that a majority agreed with the basic proposal had several beneficial effects:
- It made the proposals more palatable to more people by getting rid of at least some issues that had made their way in to the final drafts.
- It forced dissenters to figure out what specific things they wanted to be changed in the proposal rather than simply being able to say “I hate this whole thing”.
- It made more people a part of the decision– whether or not they voted for it, if some of their ideas were in it, they felt some ownership for having help craft it.
- And perhaps most importantly, it let everyone know that the door of communication still worked. People found that their ideas were still valued by the other members even if they didn’t agree with each other on the overall picture.
So what can we do with this? Maybe it’s too much to ask that we look over every little decision we make where there’s disagreement and attempt to find every last bit of common ground that we can (There were certainly times when it seemed to take forever to make a decision) but what about decisions that are close votes? What about decisions that have days-long threads as part of their backstory? In these cases, consider the proposal that the majority agrees on to be a strawman. A starting point from which to start chipping away to see what changes can be made that are still acceptable to the majority while addressing many of the issues that the minority has. Remember that the goal is to craft a compromise that addresses as many concerns as possible.