tag:blogger.com,1999:blog-237167852024-03-06T00:05:23.583-07:00ktdreyer"Well, really," said Syme, "I don't know any profession of which mere willingness is the final
test."
"I do," said the other—"martyrs. I am condemning you to death. Good day."ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.comBlogger44125tag:blogger.com,1999:blog-23716785.post-36843688880831722212021-12-22T08:07:00.005-07:002021-12-22T09:27:49.042-07:00Intro to Koji video<p>(Cross-posting here from <a href="https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.org/thread/FRW3PSV3WAFNWD4WONLG2JFBIAU5CXOF/">koji-devel</a>)</p><p>This week I created an Introduction to Koji video. <a href="https://pagure.io/koji/">Koji</a> is the build system we use for the Fedora Project and Red Hat products.</p><p>This video answers the following questions:</p><ul style="text-align: left;"><li>
What is <span class="il">Koji</span>, and how does it work?</li><li>What is the history of <span class="il">Koji</span> in Fedora?</li><li>What are the unique design features of <span class="il">Koji</span>? <br /></li></ul><p> </p><p></p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/B0xfsJ1G4v0" width="320" youtube-src-id="B0xfsJ1G4v0"></iframe></div><br /> Direct link here: <a href="https://youtu.be/B0xfsJ1G4v0">https://youtu.be/B0xfsJ1G4v0</a><br /><p></p>ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-46758454889427364862020-10-07T11:00:00.000-06:002020-10-07T11:00:35.316-06:00How to succeed at Red Hat<p>I met someone recently who just graduated college and was on the job search. I linked him to my favorite <a href="http://johnpoelstra.com/job-interview-preparation-79/">podcast episode</a> on this topic. After listening to the episode, this person then asked me:<br /><br /><b>"What kind of person would succeed as a company such as Red Hat?"</b><br /><br />I love this question. I asked around, and one <a href="https://github.com/mprahl">colleague</a> gave the following answer:<br /><br /><b>"I'd say someone that is passionate about enterprise technology and loves to learn in a fast moving environment."</b><br /><br />I love this answer, and I'm going to break it into pieces to explain why this applies.<br /><br /></p><h4 style="text-align: left;">"Passionate"</h4><p><br />This means that you understand more than just code. It means you understand the business (who our customers are, and how do we make customers happy, and why would people pay us money). It also means that you care about your work: you understand who your users are, and you think about how to improve the experience of those users consuming the work that you produce. <br /><br /></p><h4 style="text-align: left;">"Enterprise technology"</h4><p><br />What's Enterprise technology? It's technology that is stable, secure, and used in a wide variety of places. You will be a good fit if:<br /><br /></p><ul style="text-align: left;"><li>You care about making things work "out of the box" so users can get going quickly without stumbling blocks or a lot of other busy work.</li><li>You like writing clear documentation to help people who are not complete experts or Linux ninjas</li><li>You care about making things stable and well-tested (understanding things like "backwards compatibility" and the <a href="https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing">different types of testing</a>).</li><li>You care about security (understanding why things like authentication, encryption and signing are important)</li></ul><h4 style="text-align: left;">"Learning in a fast-paced environment"</h4><p><br />In Enterprise software, there is a natural pull to move slowly and stagnate. However, open-source is gigantic and moves incredibly fast. (In fact, the core of Red Hat's value proposition is that Red Hat drives innovation in "upstream" projects and then distills that down into stable products that customers can trust.)<br /><br />I've been at Red Hat for six years, and the product and technology landscape has changed a lot. During that time, Red Hat acquired Ansible and we've integrated so many things with that now. Ceph used to just integrate with OpenStack, and now we've integrated Ceph with NFS, iSCSI and OpenShift as well. Every year I work on different things and find new ways to integrate new and different projects together.<br /><br />When I joined Red Hat in 2014, I did not know Python or C++. One of the best things about accepting the job was that I knew I would be surrounding myself with people who knew these languages incredibly well. I picked up so much by osmosis, working alongside some senior developers on the team who could patiently explain things to me.<br /><br />Technology aside, a few years ago I found the <a href="https://www.manager-tools.com/podcasts">Manager Tools podcast</a> and learned so much about how to communicate effectively (really important at Red Hat were so much work is remote work). I also found a <a href="http://johnpoelstra.com/">coach</a> and learned how to get really clear on what I want, how to set boundaries effectively, how to finish projects on time, and how to handle personal challenges at work.<br /><br />"Being a passionate learner" does not mean the <a href="https://twitter.com/emilykager/status/1313303791186268160">often-ridiculed caricature</a> of the programmer who spends every spare night and weekend away from family slaving away on open-source for free. It means someone who spends their time effectively, someone who knows how to balance the critical fire-fighting of the moment with the time to make long-term investments (whether that's technical research or organizational relationship-building). In fact, one of the things I'm passionate about is quitting work on time (or even early) and encouraging folks on my teams to do the same. Quitting on time is how we keep coming back tomorrow.<br /><br /></p>ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-60546899714429642312020-05-02T11:24:00.002-06:002020-05-02T11:26:03.056-06:00in defense of code coverage<h3>
"How much do I care about code coverage?"</h3>
<br />
"100%!" (Kidding.)<br />
<br />
<a href="https://www.sqlite.org/testing.html">SQLite's article on testing</a> is helpful in this discussion. SQLite famously has 100% code coverage, but developers still find and fix bugs in SQLite. Why? Because code coverage is just <i>one</i> part of a testing strategy.<br />
<br />
When I find a software project that publishes code coverage metrics, it tells me some things:<br />
<br />
<ul>
<li>The developers know what a unit test is, and they care about writing tests. This increases my confidence in the stability of the project and my respect for the developers.</li>
<li>If I contribute to this project, I will need to learn enough to contribute a test for my feature as well.</li>
</ul>
Yes, it's helpful to know the percentage of code coverage for a project. "100%" doesn't mean the project is bug-free. It means that the developers care about shipping quality software, and they have an (imperfect) metric to help achieve that outcome.<br />
<br />
<h3>
Who are my expected users?</h3>
<br />
This question informs how much effort I put into code coverage.<br />
<br />
<b>A)</b> I'm writing <a href="https://github.com/red-hat-storage/errata-tool">a library</a> or <a href="https://github.com/ktdreyer/koji-ansible">API</a> that will be used in many different ways by different teams that do not communicate with me or each other: code coverage tools are very important.<br />
<br />
<b>B)</b> I'm writing <a href="https://github.com/ktdreyer/rdopkg-tar">a specialized tool</a> that will only be used in one well-understood case by my immediate team of developers: coverage is nice to have, but I don't prioritize this as much.<br />
<br />
<b>C)</b> I'm writing a one-off script that I will only be the sole user: This depends on a lot of factors of course, but normally I'm not going to put much effort into writing tests.<br />
<br />
Of course the answer to "who are my expected users on this project?" can change. One time I wrote <a href="https://github.com/ktdreyer/jenkins-job-wrecker">a project</a> for myself that ended up drawing a lot of unexpected users. It's important to periodically reevaluate the nature of a project's user base. Example: "Given the last 12 months, have my users' expectations for stability and quality changed?"<br />
<br />
<h3>
How are my users changing?</h3>
<br />
On <a href="https://github.com/ktdreyer/koji-ansible">one project I wrote</a>, my first user base was very small. It consisted of developers and hackers who were very involved with feedback, design, and testing. Those original users moved on to other responsibilities, and new users have replaced them who are unfamiliar with the code. They have very different expectations and want your project to "just work".<br />
<br />
<br />
This is an entirely different scenario. Documentation and regression testing are critical to sustaining the growth of the project. The new user base does not share the initial users' tolerance for breaking changes.<br />
<br />
Bug reports will continue to come in. On <a href="https://github.com/ktdreyer/koji-ansible/issues/155">one recent bug report</a>, once I identified the root-cause and the exact function that is buggy, the next question I ask is "Do the unit tests cover this method?" Code coverage tools can quickly answer this question. This makes it easier for me to confidently modify the method because I know that I'm not introducing regressions.<br />
<br />
<h3>
Summary</h3>
<br />
Unit tests and code coverage are important, and the question is "how important?".<br />
<br />
The best way to evaluate the importance of unit tests and code coverage is asking the question "What is today's cost of introducing and fixing a regression"? On a personal project, it's very low. On a popular core library with many users, the cost is very high. To answer that question accurately, you must understand your users.ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-57615526793915758072019-01-08T16:43:00.000-07:002019-01-08T16:43:39.673-07:00nightly builds are too fast and too slowI love build systems. I love working on them because it's such a unique blend between development and operations. A great build system is a great foundation for delivering value to users.<br /><br />One term I often hear is "nightly build". As in, "Where can I download the nightly build?" or "Let's set up a nightly build."<br /><br />"Nightlies" is a concept from the time where you'd set up a cron job to build your code from source control. You just poll CVS or Subversion every 24 hours, and build whatever's there. Tack a datestamp on the end of the build artifact and you're good to go.<br /><br />In this post I want to talk about how "nightly" is almost always the wrong concept. They are too frequent, or else they are not frequent enough. Or if you're writing a catchy blog post title, they're too fast and too slow.<br /><br />
<h3>
Nightlies are too slow</h3>
When you write code and test it, you want that feedback loop to be as tight as possible. Write code, save, compile, test - the faster these things happen, the faster your brain stays engaged. <br /><br />If you have to sit and wait a few minutes to get information back about whether your code is correct or your build process succeeded, you're going to context switch to something else and lose time when you forget to switch back.<br /><br />When we reach build processes that take hours, now we're in the "Meh, I'll check it when I'm back from lunch" territory. At that rate, you're probably only going to be running that process three or four times a day, max. Your workday is only eight hours, after all. The thoroughput for your changes drops through the floor.<br /><br />Now imagine extending that feedback loop even further, to a full 24 hours. You've just arrived at the "nightly build".<br /><br />When that nightly build breaks, you have eight working hours to fix it and then you get to wait again for tomorrow morning when you find out the new problem.<br /><br />After a few days of this, you no longer arrive at work with the same positive mental energy. Your morning email inbox experience becomes a thing where you discover what has gone wrong during the night, because you never saw it go right during the daytime.<br /><br />Operational tempo slides further, because it feels like "everything takes so long around here." Teams lower their optimistic expectations that anything should ever happen quickly.<br /><br />I've seen several odd knock-on effects here.<br /><br />Sometimes what happens then is that you have multiple "nightlies" for a single day. One is the first broken nightly that ran in cron, and the others are multiple attempts where someone ran the script by hand trying to get it to pass. The "nightly" is no longer nightly. Odds are that those manual runs did not do everything exactly like the full cron job did. More confusion ensues across the organization.<br /><br />When we only run a big ugly task once at midnight, then we don't care strongly about how long it takes. We've removed a big incentive to pay down the tech debt and work on shortening the long tasks, because they always happen while we're asleep. The big ugly tasks get progressively longer and longer, until an important emergency happens, and we have to run the task during working hours and we're unable to deliver in a timely way.<br /><br />Another common papercut: someone will increase the frequency of the cron task so that it runs hourly, or every 20 minutes, instead of 24 hours. This is better, but unfortunately 20 minutes is still quite slow, and users will frequently multi-task away and forget to see the failure until hours or days have gone past. There is also something maddeningly unclear about this type of every-couple-of-minutes scheduling. Is that cron job going to kick off at the top of the hour, or some other time? Did I just miss it and I have to wait the full 20 minute period, or will it happen sooner? Should I bother someone if nothing appears to be happening, or did I just do my clock math wrong? This user experience is particularly demoralizing.<br /><br />Increasing the cron task model's frequency also leads to the next problem, which is:<br />
<h3>
Nightlies are too fast</h3>
If you have a project with code that changes daily, then yep, you want to build it at least daily. But does your project change literally every day 365 days of every year? For most projects, the answer is no. Did any code really change on Saturday? Or Sunday? Not just one weekend, but every weekend?<br /><br />If we simply build every day (or even every weekday), this only works for projects that always have one or more changes every 24 hours, on to infinity. In the case where nothing has changed in the last 24 hours, then we are needlessly rebuilding for no reason. If your artifacts are multiple gigabytes, stored on highly available storage, that is a lot of duplicated disk space.<br /><br />There is also an impact to the rest of the pipeline here. If the QE team thinks they have to test every build, they may be wasting human effort and compute costs.<br /><br />The typical improvement in this case is to build some kind of polling in, like "Poll this GitHub repository every day and run a build only if there are changes from last time". Jenkins in particular has really helped spread this model, because it can do this out of the box.<br /><br />For small projects, it's usually trivial to answer "did anything change here"? For example, it's really easy to run "git fetch" and see if there are any new changes, and then build those. <br /><br />Sometimes your build process depends on many other things besides that single Git repository. For example, if you build a container that includes artifacts from several locations, then you will need to poll all of them to know if anything has changed. Many times those those locations are not trivial to poll with a one-liner.<br /><br />Now you are in a poll-the-world model, asking yourself how to poll, what is a reasonable frequency to poll, and how annoyed will those administrators be if I hit their systems every 60 seconds?<br /><br />These questions lead to spending more engineering effort or taking shortcuts which the QE team must pay for later.<br />
<h3>
What should we do instead?</h3>
Instead of talking about "nightly builds", let's talk about "CI builds".<br /><br />Instead of a poll-the-world model, make the build systems event-driven.<br /><br />This requires having a really solid grasp of your inputs and outputs. For example: my Jenkins job should fire if the code changes in Git *or* if one of the input binaries change versions, *and* it should feed its pass/fail status into these other three systems."<br /><br />If you don't know the input events for your process, research more about the system that is upstream of you, instead of simply configuring your system to poll it.<br /><br />Set the expectation that all the build pipeline processes for which you are responsible will happen immediately, without polling. This implicitly sets other expectations for all your other teams, particularly those upstream and downstream to you.<br /><br />For the dev teams feeding into your build system, they should expect actions to happen immediately. If a developer does not see the build system immediately respond to their changes, their first mental response should be "that's broken and we can fix or escalate it" instead of "it's just slow" or "it's just me".<br /><br />For QE teams that take output from your build system, you're communicating two things with an event-driven model. Firstly, when QE talk directly to a developer (skipping your role in the pipeline), and the developer says they've pushed some code, QE should immediately be able to see that the new code is building and is coming towards them. They should be checking the health of the pipeline as well, with positive expectations that they do not need to do complicated polling or involve you. Secondly, the fact that builds can arrive *at any time* means QE should set up their own automated triggers on your events, rather than polling you every 24 hours.<br />
<h3>
Technical implementations</h3>
Making all your tools event-driven is a long process, and in large systems it can take years. It's a culture shift as well as a technical shift.<br /><br />You can definitely go a long way by using GitHub's webhooks and running everything in a single Jenkins instance.<br /><br />When that no longer scales, you can run a message bus like RabbitMQ or ActiveMQ. At my current employer we have a company-wide message bus, and almost all the build and release tooing feeds into this bus. This lets each engineering team build operational pipelines that are loosely coupled from each other. There is a upward spiral effect: the more tools use the unified message bus, the more other tool authors want to use it. The messagebus has strong management support because it is the backbone of our CI efforts.<br /><br />When all the automated stuff like webhooks or a messagebus are great, of course it is a good idea to build fallback support for polling as well in the off-chance that the messages do not get through. But polling should be the fallback position to get you past an emergency, not the norm. <br /><br />
<h3>
Conclusion</h3>
We already have to wait for many things with our computers. Don't make "wall clock time" one of those things.<br /><br />Don't build nightly. Build continuously on each change event.<br />ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-84235587753760655632018-07-18T15:56:00.001-06:002018-07-18T15:57:06.505-06:00"What problem are we trying to solve?"I was in a meeting with some folks recently where the leader opened the floor for <i>Suggestions</i>.<br />
<br />
At this point the meeting got very quiet. Not everyone in the group is an introvert, but everyone felt the awkwardness and no one wanted to speak up and sound dumb.<br />
<br />
I'm not sure what was happening in everyone else's minds at that point, but for myself, I wasn't even sure what we were talking about. We were all staring at a blank whiteboard, going to write down "ideas" about ... something.<br />
<br />
I finally asked:<br />
<br />
<blockquote class="tr_bq">
"Man I'm sorry, I'm just not following here. What problem are we trying to solve?"</blockquote>
<br />
The leader next listed out three problems that he saw as important. We wrote them down and it kicked the conversation into gear. People started engaging with the list, asking, "Is that a big problem?" or "Here's how I see that problem manifesting."<br />
<br />
Sometimes brainstorming sessions or conversation-starters can be <i>too</i> open. We want to not leave anybody out, and seek ideas from everyone, so we cast such a wide fishing net that it's awkward. The conscious people are wracking their brains trying to figure out what the leader is asking for on this fishing expedition.<br />
<br />
Next time you're in a meeting that's really hard to follow, and several folks are falling silent, don't assume it's "just you". Throw yourself under the bus in a whimsical way and ask aloud:<br />
<br />
<blockquote class="tr_bq">
"Sorry, I'm lost. What problem are we trying to solve here?"</blockquote>
<br />
The next 20 minutes will be a lot more interesting!ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com2tag:blogger.com,1999:blog-23716785.post-24910097704884494132018-06-08T10:33:00.000-06:002018-06-08T10:33:48.059-06:00Hope is my strategyOne of my favorite tech books is <a href="https://landing.google.com/sre/book/">Google's Site Reliability Engineering book</a>. They open with this tongue-in-cheek quote:<br /><br /> "Hope is not a strategy" -- Traditional SRE saying<br /><br />This attitude reminds me of the common idea in system administration that anything that can go wrong will go wrong. Murphy's law, "never trust a happy system administrator", and so on.<br /><br />When your goal as a system admin is "100% service uptime", there's simply no way to meet that goal. You can only fail.<br /><br />The authors of the SRE book look at the business costs and value to uptime metrics. They propose a different strategy, focusing on an "error budget" instead of a pure 100% uptime unachievable goal. Exposing this error budget allows the business decision makers to align with the inherent constraints engineers face when making speed vs safety decisions.<br /><br />"Hope is not a strategy" means making our decisions data-driven rather than wishful-thinking-driven.<br /><br />Operating like this means gathering a *lot* of data. Lots of monitoring, A/B testing, phased rollouts, and so on.<br /><br />How much data is enough, though?<br /><br />If you're Google or another big corporation, you can spend a lot of resources on monitoring and benchmarking. There's always more to measure, tweak and improve.<br /><br />In my own life I can see the effects of wanting more and more data before making big personal decisions. It often means I delay beyond what's reasonable and miss out on opportunities because I'm risk-averse.<br /><br />There's two sides to this problem:<br /><br />- Bad: Wishful thinking, blind optimism, recklessness,.<br />- Also bad: Analysis paralysis, perfectionism, fear.<br /><br />In 2018 I've faced some hard decisions in my personal life, where I have to make choices every week for how I'm going to live and what I'm going to do. These choices affect others around me as well.<br /><br />At some point I have to stop gathering data. I don't have the resources to do the exhaustive research I daydream about for every decision. And even if I did, it's pure fantasy to think I can avoid pain and suffering in this life.<br /><br />This prayer about serenity has really helped me this year:<br /><br /> God grant me the serenity<br /> to accept the things I cannot change;<br /> courage to change the things I can;<br /> and wisdom to know the difference.<br /><br />Of course I have to dig in and do the hard work - that's the "courage to change" part. But when decisions are murky, things are unclear, that is where serenity and wisdom come in. That is where hope is my strategy.<br /><br />Where does your hope lie?<br />ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-29793557122716192882018-02-06T20:55:00.003-07:002018-02-06T20:55:59.207-07:00What is the place for one-on-one communication in open-source?One of Red Hat's mantras is "develop in the open". There is an entire website, opensource.com, with tons of articles about this idea (<a href="https://opensource.com/open-organization/resources/open-org-maturity-model">this article</a> in particular is great).<br />
<br />
One aspect of "develop in the open" means keeping conversations as public as possible. Don't email or IM a developer directly; instead, email a development mailing list (possibly using the To: and CC: fields for your intended developer) or public IRC channel instead. It's hard to overstate the community benefits of this, and again opensource.com explains the benefits in more detail than you could ever want.<br />
<br />
Sometimes people send me direct instant messages seeking information, instead of asking in a public channel. I think there is a fear of "spamming the channel" or fear of looking foolish. I can respect people's desire to avoid looking foolish. I've even done the same, and some wise people called me out on it. I suggest that you will not look nearly as foolish as you expected, though. Let's face it, if this topic was so obvious, you would have found some documentation on it already, right :) Maybe things are just hard to figure out! Maybe many other people would benefit from this probably-under-documented information!<br />
<br />
In these conversations, I try to steer back into an IRC channel, replying "That's a great question. Would you be ok if we continued the conversation in #channel-that-relates-to-what-we-are-talking-about?" Then I tab over to that channel and say "so-and-so: we were just discussing <my rephrasing of their question>" to give some context to everyone else in the room. Then I answer the question so everyone can see it.<br />
<br />
I've been thinking about a corollary to this concept this week: There is also a time for one-on-one IM conversations, and that is when you have to bring up a sensitive topic and you need to build some relational credibility.<br />
<br />
Let's say I've noticed a mistake in some code or process. Let's also imagine I do not have positive relational credibility with the person responsible. Maybe this person is a different personality type than me, and we both drive each other nuts. Maybe it's been a pressure-cooker situation for any number of other reasons. If I bring up this person's mistake in a public IRC channel, we just go deeper on the negative spiral, and my behavior can look threatening. I've found it's more effective to bring up mistakes as privately as possible.<br />
<br />
Of course we want to default to open and develop in the open. On the other hand, sometimes there is a greater good, where we a trade bit of openness for relational credibility. Once the relationship is there, maybe we'll get a chance to discuss future problems more openly without fear.ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com2tag:blogger.com,1999:blog-23716785.post-61457772297928138162017-06-28T11:23:00.000-06:002018-02-06T16:42:23.675-07:00Forwarding gpg-agent to a containerI use Fedora on my main laptop, but sometimes I need to GPG-sign something in an Ubuntu environment.<br />
<br />
I store my GPG key on my Yubikey and access the device with gpg-agent. Here are instructions for forwarding my gpg-agent connection into a Docker container.<br />
<br />
This will only work on with a ubuntu:xenial image and newer, because Trusty has GPG 2.0, and this needs 2.1. Earlier versions of GPG 2 failed because they still need access to the data in secing.gpg. See https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring for more information.<br />
<br />
On the host, bind-mount the gpg-agent socket when running the container:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">docker run --volume /home/kdreyer/.gnupg/S.gpg-agent-extra:/gpg-agent
--env GPG_AGENT_INFO=/gpg-agent:0:1
-ti ubuntu:xenial</span><br />
<br />
Within the container:
Xenial's gpg2 looks for the socket in ~/.gnupg, ignoring GPG_AGENT_INFO, so we have to link it in:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">mkdir -p ~/.gnupg && chmod 700 ~/.gnupg</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">ln -s /gpg-agent ~/.gnupg/S.gpg-agent</span><br />
<br />
Trust the kdreyer@redhat.com key:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">gpg2 --keyserver keys.fedoraproject.org --recv 478A947F782096AC</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">echo -e "trust\n5\ny\n" | gpg2 --command-fd 0 --edit-key kdreyer@redhat.com</span><br />
<br />
Test a signature operation:<br />
<span style="font-family: "courier new" , "courier" , monospace;">echo hi | gpg2 -as -u kdreyer@redhat.com --use-agent </span><br />
<br />
Now we can use GPG with other tools, for example debsign:<br />
<span style="font-family: "courier new" , "courier" , monospace;">debsign -p gpg2 tambo_0.4.0-0ubuntu0.16.04.1_source.changes</span><br />
<br />
Note there's a bug in dput that it hardcodes the use of /usr/bin/gpg when verifying sigs, so you'll have to import your key again into the gpg1 key store:<br />
<span style="font-family: "courier new" , "courier" , monospace;">gpg --keyserver keys.fedoraproject.org --recv 478A947F782096AC </span><br />
<br />
And then you can upload to a Launchpad PPA:<br />
<span style="font-family: "courier new" , "courier" , monospace;">dput ppa:kdreyer-redhat/ceph-medic tambo_0.4.0-0ubuntu0.16.04.1_source.changes</span>ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-81420047940290035752015-09-01T13:32:00.001-06:002018-02-06T16:37:57.066-07:00Red Hat on NPR<a href="https://soundcloud.com/fatherlinux/red-hat-on-npr">https://soundcloud.com/fatherlinux/red-hat-on-npr</a><br />
<br />
:)ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-36790268210458667472014-10-29T21:54:00.000-06:002018-02-06T16:42:36.736-07:00Sigal packaging and CentOS<br />
My home server was running CentOS 6, and this was getting a bit long in the tooth:<br />
<br />
<ul>
<li>The libwww-perl version that ships in CentOS 6 does not handle HTTPS
certificates in a secure way. This was only fixed in LWP version 6.
There's almost no chance of LWP getting rebased, since that module is
part of Perl core, and it's so late in the RHEL 6 lifecycle.</li>
<li>The Python version (2.6) is so old that many Python apps no longer
support it. The one I was particularly interested in was Sigal to
generate my own photo gallery for my family.</li>
</ul>
<br />
I tried using the <a href="http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/">Python 3.3 software collections</a>, and this worked well to get Sigal running in a Python 3.3 virtualenv.<br />
<br />
For
Perl, I didn't want to deal with SCLs, because my application has a long
dependency chain, and I would need to rebuild a lot of SCL-style RPMs to
get my app to work. I could just use the "<span style="font-family: "courier new" , "courier" , monospace;">cpan</span>" tool (similar to
<span style="font-family: "courier new" , "courier" , monospace;">virtualenv</span>/<span style="font-family: "courier new" , "courier" , monospace;">pip</span>), but I wanted to avoid the security and stability issues
associated with using an essentially random snapshot in time of modules
that I grabbed<span class="sewosqrbylpkaey"></span><span class="sewosqrbylpkaey"></span>
from upstream. I like the fact that Bugzilla is a central place to
track CVEs, and I like the waiting period in epel-testing and the
possibility for community collaboration there, etc.<br />
<br />
The idea of
using multiple SCLs and lots of non-packaged upstream modules was what
pushed me to just bite the bullet and update to CentOS 7. CentOS base +
CentOS extras + EPEL 7 already had all the deps for Sigal, except
python-pilkit. I buckled down and learned just enough Python packaging
techniques in order to package <a href="https://fedorapeople.org/cgit/ktdreyer/public_git/python-pilkit.git/">python-pilkit</a> and <a href="https://fedorapeople.org/cgit/ktdreyer/public_git/python-sigal.git/">python-sigal</a>. And the best part is that the packages actually work on my new EL7 system (knock on wood).<br />
<br />
sigal
bundles some Javascript bits, and I'm not sure about the JS guidelines
for EPEL. But otherwise I think the packages are close to being ready to
submit to Fedora.ktdreyerhttp://www.blogger.com/profile/07811896753757483829noreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-19529019895299700242013-12-04T21:57:00.001-07:002013-12-04T21:57:06.422-07:00work<blockquote class="tr_bq">
"What we want is not more little books about Christianity, but more little books by Christians on other subjects—with their Christianity latent."</blockquote>
<br />
- <a href="http://www.cslewisinstitute.org/What_if_the_best_work_was_always_done_by_a_Christian">C.S. Lewis</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-1643042203159568392010-04-15T17:15:00.002-06:002010-04-15T17:25:10.380-06:00Typepad AntispamI've just set up Typepad's open-source Akismet backend, also known as <a href="http://antispam.typepad.com/">"Serotype"</a>. This software internally uses <a href="http://www.danga.com/perlbal/">Perlbal</a> for communicating HTTP, <a href="http://gearman.org/">Gearman</a> to delegate instructions, and <a href="http://www.nuclearelephant.com/">dspam</a> for content-based spam filtering. Other software requirements are MySQL and memcached.<br />
<br />
Documentation is pretty scarce; a README file is basically all you get. However, if you're familiar with Perl you should be good to go. I put the pieces together in a CentOS 5 VM. Many of the required Perl modules were already in EPEL, but I did have to get some things directly from CPAN.<br />
<br />
Here are my initial thoughts:<br />
<ul><li>Thank you TypePad for making this open source, and releasing it to the world! </li>
<li>Most of Typepad's software is in Perl, and they are the creators of Perlbal/Gearman, so no surprise that this software is based on that as well. Since it uses Gearman, this Serotype server should be able to scale massively.</li>
<li>Once I installed all the required Perl modules, the software essentially worked "out of the box". I did need to adjust the Gearman client timeout to fifteen seconds. I traced this delay to the yuidd daemon. I'm not sure why it can take up to ten seconds to give me a UID.</li>
<li>The handling of API keys is very loose; the web service accepts API key by default. However, only keys that are "blessed" are able to actually train the database.</li>
<li>I wish there were an easier way to "prepopulate" the database with spam.</li>
</ul>Web forms are the spammers' new battlefields. Good thing the Akismet API even exists.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-33336790036059370592009-12-01T12:00:00.009-07:002010-06-12T14:31:52.850-06:00Life After Graduation<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiro3Tt3AqjAiw6wWfljrVg2qOKkow4MOQORu2Fe5gUoZ2uWtg2NziGh0LvQquj73Ayagotra0Nrnjb_uezyLHISpMTQm4QPlqOzldRTfm8AMtq9QHPFLfGagKZWZekTA28Gnihyg/s1600/IMG_4577.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiro3Tt3AqjAiw6wWfljrVg2qOKkow4MOQORu2Fe5gUoZ2uWtg2NziGh0LvQquj73Ayagotra0Nrnjb_uezyLHISpMTQm4QPlqOzldRTfm8AMtq9QHPFLfGagKZWZekTA28Gnihyg/s320/IMG_4577.JPG" /></a></div><p>Wedding in IL</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtnehzvse87VkgkeKsE_Ef02eaQU_OBNkEX21MQSjbHjdkOOvV9dBKWvJ68ApaiO06xTa7s1kVdXmZFDHUCU5bpHODDBdQ6CgFxNanN91FfAQ1rUCIl0APipX_hCxDxzhZlBlq4Q/s1600/06-13-09_1809.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtnehzvse87VkgkeKsE_Ef02eaQU_OBNkEX21MQSjbHjdkOOvV9dBKWvJ68ApaiO06xTa7s1kVdXmZFDHUCU5bpHODDBdQ6CgFxNanN91FfAQ1rUCIl0APipX_hCxDxzhZlBlq4Q/s320/06-13-09_1809.jpg" /></a></div><p>Honeymoon in VA</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFA5_uXUeCNjiry4mGQT3UhJd6WoEwphgj6m5-nEv8lVkMx8ACXmaqhyISfY2SDn2LCywRkBWMNHpnAJ_cZhpxPIqcQnkJFv3MebPJvJOwR8GqrCa8OIj4hKwBFye5_xf2dPmjSQ/s1600/DSC02930.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFA5_uXUeCNjiry4mGQT3UhJd6WoEwphgj6m5-nEv8lVkMx8ACXmaqhyISfY2SDn2LCywRkBWMNHpnAJ_cZhpxPIqcQnkJFv3MebPJvJOwR8GqrCa8OIj4hKwBFye5_xf2dPmjSQ/s320/DSC02930.JPG" /></a></div><p>Beach Trip with Dreyers in NC</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiQruOd8YlOCSSZqxP7QodJaG9ph_IhsRSWRg3YbV1WA69cObHltM9IcdMH4SUxikIa_AOj2Kp9K2fqCU7OcIlN8skBfVLRHvTB2pFg-gssbx0Lxezns96Ys5Jm_nfVqUQfelmHA/s1600/ken-23-bday.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiQruOd8YlOCSSZqxP7QodJaG9ph_IhsRSWRg3YbV1WA69cObHltM9IcdMH4SUxikIa_AOj2Kp9K2fqCU7OcIlN8skBfVLRHvTB2pFg-gssbx0Lxezns96Ys5Jm_nfVqUQfelmHA/s320/ken-23-bday.JPG" /></a></div><p>Birthday in Littleton CO</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAIkS4rujYSCIt7u8vTApaOMVd0ZR2SPqmBsBUGJTVHFx80jW8lTrNVKSVnDy5XMAcMgb1qC8_IZVPqdlRSF_hJ-DmVSG-Tvg62yuc88jqT4__oD4sDZgysdfR0FCMuhx8DP38IQ/s1600/09-26-09_2059.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAIkS4rujYSCIt7u8vTApaOMVd0ZR2SPqmBsBUGJTVHFx80jW8lTrNVKSVnDy5XMAcMgb1qC8_IZVPqdlRSF_hJ-DmVSG-Tvg62yuc88jqT4__oD4sDZgysdfR0FCMuhx8DP38IQ/s320/09-26-09_2059.jpg" /></a></div><p>Skillet concert in VA... in the rain</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlPlwZPb4G0sODa3_8cQTy6lG6yPqDn9El1IRjJZv-RvLVCSxiDn_1Qveswi68CZrZEnruNdc85EUmlpg9AEPdTngpJeBpjwYV1uP5VjXE0tNDCNRMOjvBwJrucCB-C7jLGr0ZRw/s1600/12-23-09_1534.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlPlwZPb4G0sODa3_8cQTy6lG6yPqDn9El1IRjJZv-RvLVCSxiDn_1Qveswi68CZrZEnruNdc85EUmlpg9AEPdTngpJeBpjwYV1uP5VjXE0tNDCNRMOjvBwJrucCB-C7jLGr0ZRw/s320/12-23-09_1534.jpg" /></a></div><p>New nephew</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-28948092577357240952009-05-30T21:24:00.002-06:002009-05-30T21:27:45.317-06:00laura-dreyer.com redesign<a href="http://www.laura-dreyer.com">Laura</a> and I spent the past three days re-designing her website, adding a blog, re-vamping the gallery... it was hectic but fun!<br /><br />6 days and counting till I'm married :-)Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-23716785.post-31349348600734973402009-05-15T17:00:00.000-06:002010-01-04T18:35:07.392-07:00Last View from MoodyI thoroughly enjoyed my time at MBI, and I won't forget the many memories from the school or the city.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkJiQoVodmL7EeV9QDMMgPJ-gD4ho1J9lW1vUxuu9BYo454U4mwoAbNRquDhzikeVZiUdhGYDO5EfEMMb3TuYLNbS7YY4TCFM4tVE1gAiTNI7n26lAKu00X0Kd3Q2l8JYeZevhXw/s1600-h/IMG00009.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkJiQoVodmL7EeV9QDMMgPJ-gD4ho1J9lW1vUxuu9BYo454U4mwoAbNRquDhzikeVZiUdhGYDO5EfEMMb3TuYLNbS7YY4TCFM4tVE1gAiTNI7n26lAKu00X0Kd3Q2l8JYeZevhXw/s320/IMG00009.jpg" /></a><br />
</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-60744040437962901682009-04-17T15:35:00.005-06:002009-04-17T15:38:42.888-06:00new kenandaudrey.com coming upWe're re-designing our wedding website to be more interactive, and it's getting a facelift in the process. Here's a sneak preview :)<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDPUEmOHdggd7OwymFdt8TtOA7XnLt760aw7Dv2tavUdsCObATNYiwVQNXl0gSr74-af9TIur1YVItPV_SUWYwIMJr2k7C2ZWCcqQM-eDw-c2-4BEx_XylYeJulFfuF7WAKqhyphenhyphenlw/s1600-h/home-mockup.jpg"><img style="cursor: pointer; width: 400px; height: 285px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDPUEmOHdggd7OwymFdt8TtOA7XnLt760aw7Dv2tavUdsCObATNYiwVQNXl0gSr74-af9TIur1YVItPV_SUWYwIMJr2k7C2ZWCcqQM-eDw-c2-4BEx_XylYeJulFfuF7WAKqhyphenhyphenlw/s400/home-mockup.jpg" alt="" id="BLOGGER_PHOTO_ID_5325777647872980098" border="0" /></a><br /><br />Also, I've re-vamped the website for Gingrich Enterprises at <a href="http://www.gei-1.com/">www.gei-1.com</a>.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-23716785.post-61451638757983720362009-04-17T15:28:00.004-06:002010-04-15T17:17:32.436-06:00RAID1 on nslu2Can RAID1 work on the nslu2 for big drives? Yes! I've got two 750 GB SATA drives hooked in, and it's humming along. I had to upgrade to <a href="http://www.nslu2-linux.org/wiki/SlugOS/SlugOS5">SlugOS5</a> in order to be able to boot to the md device. Be ready for long RAID sync times though... it's taking about 21 hours to sync a 650 GB partition :)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-21630968085682051782009-03-29T20:02:00.004-06:002009-03-29T20:28:24.998-06:00Authenticating Wordpress with multiple domains in Active DirectoryRecently I've been working on a project involving authenticating Wordpress to Active Directory. There's a great plugin on wordpress.org for doing <a href="http://wordpress.org/extend/plugins/active-directory-authentication/">AD authentication</a>, but I needed it to do a bit more than the author intended. The main thing I needed was support for authenticating users from many different domains.<br /><br />In the original plugin, there is a single, universal "account suffix", stored in the Wordpress settings database. I'm guessing the intent here is to have a user simply enter their username, like "kdreyer", and have the suffix automatically appended to it ("kdreyer" + "@example.com"). Since we're using multiple domains, this won't work. I could have a "kdreyer@example.com", or a "jsmith@xyz.com", and I need to authenticate both.<br /><br />So here is my hacked version of the Active Directory Authentication plugin. It pulls out the domain from the user's account using <code>split('@', $username)</code>, and uses the user-supplied suffix instead of the universal suffix. This means I can get rid of the global Account Suffix and Default Email Domain settings altogether.<br /><br />There are one or two other modifications here as well. I'm using SSL in my adLDAP instantiation... and so should you ;-) I've also added a bit to update the user's display_name to be "John Smith", instead of jsmith@xyz.com... the info's already there in AD, so, why not help our user out and put it in there for him :-)<br /><br />I'm using Wordpress 1.7.1, and the patch is against Active Directory Authentication plugin 1.0.5.<br /><ul><li><a href="http://ktdreyer.googlepages.com/ad-auth.php">plugin</a></li><li><a href="http://ktdreyer.googlepages.com/ad-auth-multiple-domains.patch">patch</a></li></ul>Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-23716785.post-54997975605869294922008-12-30T20:38:00.004-07:002008-12-30T20:43:56.971-07:00Laura's websiteJust finished 1.0 of my sister Laura's website, <a href="http://www.laura-dreyer.com/">www.laura-dreyer.com</a>. Laura designed the whole thing in Inkscape, I carved it up with GIMP, put it into a custom Wordpress theme, and put the finishing touches with jQuery. It was really fun and I learned a lot along the way. Laura's a great designer (and sister :)<br /><br />Going to pick Audrey up in a few hours from the airport... our final un-married New Year's :)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-62605013938070112212008-12-10T19:21:00.007-07:002010-01-07T19:40:41.612-07:00"trick" interviewsApparently giving "trick" interviews is as popular as it is unprofessional.<br />
<br />
Ethically, is there a difference between what <a href="http://www.youtube.com/watch?v=Q1iuEcu7O50">Michael Moore does to Charlton Heston</a> in <span style="font-style: italic;">Bowling for Columbine</span> and what certain <a href="http://www.skeptics.com.au/publications/articles/the-information-challenge/">creationists have done to Richard Dawkins</a>?Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-21016908860134850732008-06-09T19:51:00.003-06:002018-02-06T16:42:48.806-07:00Fedora 9 impressionsI've been running Fedora 9 for a while now. Although some things in F8 felt half-baked to me (I had trouble with PulseAudio + Audacious), F9, like each Fedora release, feels more polished.<br />
<br />
Improvements:<br />
<ul>
<li>Yum is <span style="font-style: italic;">much</span> faster - not as fast as apt, but getting there.</li>
<li>PackageKit is <span style="font-style: italic;">much</span> more polished than the package manager GUI F8 used (Pirut and Pup).</li>
<li>Swfdec works pretty well!</li>
</ul>
<br />
Gripes:<br />
<ul>
<li>Firefox 3 occasionally crashes, and many plugin authors haven't updated their plugins to version 3.</li>
<li>Gkrellm: I haven't seen an error window like <span style="font-style: italic;">this</span> in a while :)<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxeqOenAXVe-b1BmK5rWed8Wvr-5QPVHtTz4Nn9kqq6Ojsf-VnyXCdUrCUa_GqqB1Z1QJNPxEPrtBQTUbnB1gVDMV1Cv20iI92jS1zGbW08Nj-eGRg0D49_tvZM4iUSLFDt2yvXA/s1600-h/gkrellm-error.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5210074453053321314" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxeqOenAXVe-b1BmK5rWed8Wvr-5QPVHtTz4Nn9kqq6Ojsf-VnyXCdUrCUa_GqqB1Z1QJNPxEPrtBQTUbnB1gVDMV1Cv20iI92jS1zGbW08Nj-eGRg0D49_tvZM4iUSLFDt2yvXA/s200/gkrellm-error.jpg" style="cursor: pointer; float: right; margin: 0pt 0pt 10px 10px;" /></a></li>
</ul>
Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-23716785.post-41468621135284129232008-06-07T09:24:00.007-06:002008-06-07T09:37:47.495-06:00summer internship<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpGHCbgNiAljbcfvQN-v22c3dRiyXGBMP3cJMe_6Ltz1KlzmfJWSk5Vf-DxdCO-sKX8l9NiIl_tZAir4hecYgaDq1Bw1-voU9nFvYp2fML7EltNu9mQoks3YvhSGAAzOqAcmtSnA/s1600-h/05-27-08_1038.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpGHCbgNiAljbcfvQN-v22c3dRiyXGBMP3cJMe_6Ltz1KlzmfJWSk5Vf-DxdCO-sKX8l9NiIl_tZAir4hecYgaDq1Bw1-voU9nFvYp2fML7EltNu9mQoks3YvhSGAAzOqAcmtSnA/s200/05-27-08_1038.jpg" alt="" id="BLOGGER_PHOTO_ID_5209163686880103506" border="0" /></a><br />I'm interning this summer at Community Bible Church, at Pocono Lake, Pennsylvania. I drove up to the area on May 24, met the pastor that night, and met the church congregation on Sunday the 25th. They are a nice bunch of folks! I was so surprised to see the sign outside the church welcoming me.<br /><br /><br />So far I've been able to teach Sunday School on Sunday mornings, lead Bible study on Wednesday nights, and redesign the church website: <a href="http://www.poconolakechurch.org/">poconolakechurch.org</a>. Tomorrow I preach my first sermon there on the book of Esther.<br /><br />My fiancée, <a href="http://audrey.ktdreyer.com/">Audrey</a>, is on a plane to the Philippines for her internship this summer, where she'll be working with the missionaries there and discipling women in the church group.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-23716785.post-38336416430770367202008-05-14T00:52:00.004-06:002008-05-14T02:02:13.946-06:00first mac experienceA friend gave me an old G3 to play around with today. It's my first Mac experience... and I promptly managed to hose Safari by installing the latest version from apple.com. Apparently OS X 10.3 doesn't support the newer versions of Safari or WebKit. After struggling around trying to downgrade back to Safari 1.3, I finally found good <a href="http://discussions.apple.com/message.jspa?messageID=7073218#7073218">instructions</a> for what I needed. Apparently I have to go back to <a href="http://www.apple.com/support/downloads/safari.html">Safari 1.2</a>, <span style="font-style:italic;">then</span> to 1.3 :) Also, <a href="http://www.charlessoft.com/">Pacifist</a> was necessary; simply installing 1.2 the regular way doesn't work.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-20670105405979332072008-05-12T11:26:00.000-06:002008-05-12T11:27:44.292-06:00big newsI'm <a href="http://www.kenandaudrey.com/">engaged</a> :)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-23716785.post-79555110236165924382008-01-13T16:42:00.002-07:002008-05-29T22:37:09.088-06:00hacking the WGR614v7Netgear often builds a telnet daemon into their routers, but sometimes it can be a little tricky getting in. I was curious to see if my WGR614v7 has any way to access a command line interface, so I fired up nmap:<br /><br /><code>$ nmap 192.168.1.12</code><br /><br /><code>Starting Nmap 4.20 ( http://insecure.org ) at 2008-01-13 17:42 CST</code><br /><code>Interesting ports on 192.168.1.12:</code><br /><code>Not shown: 1694 closed ports</code><br /><code>PORT STATE SERVICE</code><br /><code>23/tcp open telnet</code><br /><code>80/tcp open http</code><br /><code>8080/tcp open http-proxy</code><br /><br /><code>Nmap finished: 1 IP address (1 host up) scanned in 1.355 seconds</code><br /><br />All right! Let's try to log in...<br /><br /><code>$ telnet 192.168.1.12</code><br /><code>Trying 192.168.1.12...</code><br /><code>Connected to 192.168.1.12.</code><br /><code>Escape character is '^]'.</code><br /><code>Connection closed by foreign host.</code><br /><br />Rats. For some reason we are kicked out as soon as we touch the daemon. A little hunting on the internet provides <a href="http://www.seattlewireless.net/NetgearWGR614">an explanation</a>. Apparently the telnet daemon is disabled by default, but the Netgear staff have a Windows utility that will send a packet to the router in order to enable the telnet interface. A hacker has somehow reverse-engineered the encryption process and written it into a <a href="http://seattlewireless.net/telnetenable.c">C program</a>.<br /><br /><code>$ gcc -o telnetenable md5.c blowfish.c telnetenable.c</code><br /><br />Now I use the program to construct the "unlock" packet with the IP and MAC address of my router, and the default username/password "Gearguy/Geardog":<br /><br /><code>$ ./telnetenable 192.168.1.12 00AABBCCDDEE Gearguy Geardog > modpkt.pkt</code><br /><br />Then I send it to the router with netcat:<br /><br /><code>$ nc 192.168.1.12 23 < modpkt.pkt</code><br /><br />Now I try to log in again...<br /><br /><code>$ telnet 192.168.1.12</code><br /><code>Trying 192.168.1.12...</code><br /><code>Connected to 192.168.1.12.</code><br /><code>Escape character is '^]'.</code><br /><code>Login: Gearguy</code><br /><code>Password: *******</code><br /><code>U12H06400></code><br /><br />And we're in! "<code>?</code>" gives a list of commands. I'm most interested getting the network statistics from this and putting the results into <a href="http://www.cacti.net/">cacti</a>... but I'll save that for another time! :)<br /><br /><h3><span style="font-size:100%;">--Edit--</span></h3>Apparently seattlewireless.net, the original website that hosted the files and information, is down. I've put the C files up for grabs here:<br /><br /><a href="http://ktdreyer.googlepages.com/telnetenable.c">http://ktdreyer.googlepages.com/telnetenable.c</a><br /><a href="http://ktdreyer.googlepages.com/md5.h">http://ktdreyer.googlepages.com/md5.h</a><br /><a href="http://ktdreyer.googlepages.com/md5.c">http://ktdreyer.googlepages.com/md5.c</a><br /><a href="http://ktdreyer.googlepages.com/blowfish.h">http://ktdreyer.googlepages.com/blowfish.h</a><br /><a href="http://ktdreyer.googlepages.com/blowfish.c">http://ktdreyer.googlepages.com/blowfish.c</a><br /><br />Good luck!Unknownnoreply@blogger.com5