Archive for September, 2005

FreeBSD 6 Updating

Thursday, September 29th, 2005

Today, we are going to discuss a basic, initial setup for updating a freshly installed FreeBSD 6 Beta 5 system to the latest stable version available at FreeBSD.org and the latest ports for all installed packages. Now, FreeBSD is not our favorite distribution of BSD, that happens to be OpenBSD, but it is the flavor of BSD we have found functional as a desktop platform, although we tend to favor Debian GNU/Linux for this purpose.

(We often refer to the FreeBSD handbook in this post, which provides valuable basics for using FreeBSD.)

The install of FreeBSD 6 is fairly clean on most i386 desktops and laptops, although wireless support on a Dell Inspiron 8500 is, as usual, a problem. (In this case, we are using a Dell similar to the one discussed in the Debian post, except it has a different video card, a larger disk and more RAM, and actually belongs to us.) The install even goes so far as to partition the disk in a traditional FreeBSD way rather than just one lump partition as many installations do by default, although we add partitions and bump up “/var” a bit. There are pre-selected package options for different types of uses for the system (such as for developers), and we can also go in and custom select/deselect other packages. We make sure to install the full src and ports trees. That is pretty much it for install.

So, once the system is up and running, what do we do?

Well, first we get it organized easily for performing updates. This means setting up cvsup for the system (“/usr/src”) and the ports (“/usr/ports”). Information on properly using cvsup can be found here in the FreeBSD handbook.

We make sure “portaudit”, “cvsupport”, and “portupgrade” are installed. If anyone of them is not installed, we install them. More information on using packages can be found here in the FreeBSD handbook.

  • pkg_add -r portaudit
  • pkg_add -r cvsup
  • pkg_add -r portupgrade

We install the full source tree and ports during the installation of the system, but if they are not there, we can perform the following, if the installation FreeBSD CDs are available. Additionally, we can just pull the files down using cvsup.

  • sysinstall
  • Select Configure
  • Select Distributions
  • Select src (this results in a selection menu for sources to be installed)
  • Under the src selection menu, Select All (you can, of course, whiddle this down)
  • Select ports
  • Select OK until these things get installed and then exit sysinstall

After this, we copy sample sup files from “/usr/share/doc/cvsup/” to “/usr”.

  • cp /usr/share/examples/cvsup/stable-supfile /usr/share/examples/cvsup/ports-supfile /usr/

The example configuration files are fine for our purpose, except for a couple of tweaks.

  • In “/usr/stable-supfile”, we change “*default release=cvs tag=RELENG_5″ to “*default release=cvs tag=RELENG_6″ since we were running FreeBSD 6 branch. A list of releases can be found here in the FreeBSD handbook.
  • In both “/usr/stable-supfile” and “/usr/ports-supfile”, we change “*default host=CHANGE_THIS.FreeBSD.org” to be one of the mirror servers. A list of mirrors can be found here in the FreeBSD handbook.

Next, we synchronize our source trees with those on a FreeBSD mirror. We are not currently running X windows, although it is installed, and we want to see the most verbose output of what is happening during the update, so we run cvsup with “-g” and “-L 2″.

  • cd /usr/src
  • cvsup -g -L 2 ../stable-supfile
  • cd ../ports
  • cvsup -g -L 2 ../ports-supfile

Ok, now that our source tree is synchronized, we are ready to rebuild the kernel and the system binaries, and then our packages.

We start with building a custom kernel and rebuilding the system binaries, since a bunch of these had updates during our synchronization. More information on building a custom kernel can be found here in the FreeBSD handbook.

First we switch to the directory containing the kernel’s build configuration for the i386, copy the GENERIC build configuration to /usr/DKript_Lap1, and symbolically link it in our current directory.

  • cd /usr/src/sys/i386/conf
  • cp ./GENERIC /usr/DKript_Lap1
  • ln -s /usr/DKript_Lap1 ./DKript_Lap1

We then proceed to edit the configuration file using vi. A great resource for what the configuration options mean can be found here in the FreeBSD handbook.

  • vi DKript_Lap1

We comment out the “cpu” entries for “I486_CPU” and “i586_CPU”. We change “ident” to “DKript_Lap1″. There are no DOS partitions that take place in our boot, so we comment out “MSDOS_FS”. We are not going to be using Tape drives nor RAID arrays with the laptop, so we comment out “atapist” and “ataraid”. We comment out all SCSI controllers, SCSI devices, and all RAID controllers as none of these are going to be used with the laptop, but we leave the SCSI peripherals enabled as there are cross dependencies with certain USB capabilities (i.e., the build breaks without them). We enable the pcvt console options. We enable power management support. We comment out virtually all of the NIC drivers, with the exception of the MII bus support, the Broadcom BCM440x, and the wireless cards. We comment out “sl”, as SLIP has no use for us. We also add the following entries to handle our wireless security protocols.

    #Need to statically link into the kernel or manually configure to load this in right now as dynamic loading of these modules not yet supported
    device wlan_wep
    device wlan_ccmp
    device wlan_tkip

Note: “dmesg | less” and “pciconf -lv” can be useful to figure out what features you need in the kernel.

With that done, we are ready to rebuild the system. This takes a long time.

  • make buildworld
  • make kernel KERNCONF=DKript_Lap1
  • reboot

The FreeBSD 6 code base is evolving quite rapidly as it is still in beta, so we treat our build as an upgrade. We boot the system into single user mode by breaking the boot and typing -s as a boot parameter. We run “mount” to check that “/”, “/usr”, “/var”, and “/tmp” are mounted properly (read/write). Then, we run the following.

  • mergemaster -p
  • make installworld
  • mergemaster
  • reboot

When the second mergemaster runs, there are a number of diffs. We install virtually all of the updated versions of files, but we had to go through them closely to make sure they did not break our setup, which is unlikely given this is a fresh install.

The reboot is quite fast when compared to the original boot after install. Perfect.

Since we have already installed all of the ports we want during install, we just want to perform an upgrade of them. We synchronized our ports tree above, so now we just have to build and install. This takes quite a while, especially if X needs to be built. First we make sure the package database is up to date and clean, and then we update all installed packages. More information on using ports can be found here in the FreeBSD manual.

  • pkgdb -F
  • portupgrade -a

After this completes and all of our packages are updated to the latest version, we run the following to see if there are any known vulnerabilities in the latest versions of the ports.

  • portaudit -Fa

Portaudit goes out and downloads the latest vulnerability list from FreeBSD, and then checks our installed ports against this list. If any of the latest versions of the packages we installed are identified as having known vulnerabilities, we assess the risk and potentially uninstall them or look for temporary workarounds until real patches are developed.

That’s about it for our basic update of a freshly installed FreeBSD 6 Beta 5 system.

VBA

Tuesday, September 27th, 2005

We are often pulled in by small businesses (and sometimes large businesses) to help with automating or otherwise optimizing their usage of Microsoft Office applications, for example Word, Excel, and Access. Many times, there are existing Visual Basic for Applications (VBA) scripts and macros that need updating or tweaking, so we found this post on the Daily WTF to be quite humorous.

This procedure’s sole purpose is to determine the string to use when setting the tail of each of the reports’ filenames to “yyyymmdd.xls”, which is supposed to reflect the prior day’s date:

Public Sub set_xlsFilename()
ZeroMonth = “”
ZeroDay = “”
Range(“T1″).Select
ActiveCell.FormulaR1C1 = “=MONTH(TODAY())”
Range(“U1″).Select
ActiveCell.FormulaR1C1 = “=DAY(TODAY())-1″
Range(“V1″).Select
ActiveCell.FormulaR1C1 = “=YEAR(TODAY())”
xlsMonth = Range(“T1″)
xlsDay = Range(“U1″)
xlsYear = Range(“V1″)

Dim RepMONTH As String
Dim RepYEAR As String
Dim RepMODAY As String

If xlsMonth = 1 Then RepMONTH = “Jan”
If xlsMonth = 2 Then RepMONTH = “Feb”

***Snip – we removed the rest of visual basic script code above, which was about another 30 or so lines. The Daily WTF post has it all.***

Anyway… today, I replaced that entire procedure with this one:

Public Sub set_xlsFilename()
xlsFilename = Format(Date – 1, “yyyymmdd”) & “.xls”
End Sub

VBA can be good for automating tasks in Microsoft Office applications, and it is easy enough to use that it facilitates use by non-programmers, which is good, but the end results of that can often be unpredictable/unmaintainable, which is bad. Also, Visual Basic (VB) in general can be useful for a quick GUI wrapper to commandline applications.

via The Daily WTF

Skype again

Tuesday, September 27th, 2005

I just saw this post by TechCrunch about the Skype roadmap, as I was catching up on my RSS/Atom feeds.

Upcoming version 1.5, schedule to be released in October, is to add video and client-side web presence features. Version 1.6, in November, streamlines the client and adds social networking, among other features.

Cool.

via TechCrunch

Also, I listened to the interview with PCHome people on the Skype blog (later realizing that the blog entry was a full transcription of the interview), and there was this little blurb about the current and future products of IPEVO.

Not only Free-1 USB phone which is selling very well. We’re going to launch a cordless USB phone, a WiFi phone and speakerphone and so on. So we have a lot of plans for the future.

This reminded me of an earlier entry on the Skype blog.

Folks in our secret undercover engineering labs were kind enough to let me play with our recent WiFi phone prototype. We’re working with many companies on a wild variety of hardware concepts and the WiFi phone is just one example.

Nothing new here, but still cool.

via Share Skype

Last note, a new version of Skype has been released for GNU/Linux, which the change log shows as fixing a number of bugs and improving call quality. And, there is a Debian package available.

Customer service and pride

Friday, September 23rd, 2005

This post strays a bit off-topic, so you might want to skip it.

We are a services company. Tech brains are our asset, but it is how we apply those brains to our customer’s needs in order to exceed out customers expectations – our service – that keeps people coming back and makes them our evangelists. In other words, we take pride in what we do, and we do it well.

Taking pride in what you do and, by virtue, doing it well… This seems simple, but, speaking for myself, this is something that I take strong notice of whenever it occurs because I find that it is just not that common. And, when you do notice it, you really appreciate it – it becomes a topic of conversation, perhaps even a recommendation. I know I like talking about talking good experiences.

My generic example of this type of pride comes from a Starbucks I visited for a couple of years, as it was close to where I used to work. There was one barista in that Starbucks that would always say hello, knew exactly what I ordered (and often had it ready before I reached the cashier), and just seemed like the energy of the place. He was clearly proud of his work and did it well, and he made that Starbucks part of my morning routine, even though there was another coffee shop closer by that had better coffee but lesser service. One morning, the line was out the door and crawled along. When I got up to the counter, I asked what had happened. It turned out that this barista had come down with the flu. Since this was an unplanned absence, the manager was only able to get one bartista to fill in instead of two (that’s right, two).

I bring this up on the blog today due to experiences I had on Wednesday (21-09-2005) night.

(For those looking for places to go… I made the rounds with a pleasant date, starting off at the Hudson bar, heading down and way over to Rififi for a spell, and then heading slightly back up and over to Marquee. The Hudson bar is a generic lounge, but it is quite empty early on and so works for a quick cocktail and conversation. Rififi is always relaxed and unpretentious, happens to have the cheapest pints of Guinness in Manhattan ($5 USD), and you can have takeout delivered there. While the Marquee’s bitter door leaves a lot to be desired, it is quite the opposite inside and upstairs – full of happy, friendly people having lots of fun.)

So, we were sitting in the Hudson bar waiting to order drinks in the evening. The place was mostly empty at this time, with a few people scattered about, including the two of us. We observed two waitresses, and the difference in their customer service was so striking that it pulled me onto the very topic of this blog post, which is also a frequent topic of mine in general. (As you can tell, I am an exciting date.)

The one waitress circled the room looking for larger groups to service. Most of the time she was just standing around, ignoring the small groups of people, but, as soon as a larger roup of people (the lower bound appeared to be greater or equal to three) walked in, she was on them like a hawk. The way she interacted with them was almost aloof, and while the drinks seemed to come at a decent pace, she never had a rapport with the customers – it just seemed like she was doing her job. And, as for us, the guy and girl sitting off to the side, we got a few looks from her, only to be passed by for service.

The other waitress there understood how to do her job well, and the pride in her work was obvious. She was always running around the room, making sure that everyone felt important. When she came over to us, she asked if we had been serviced yet – when we said no, she apologized for the delay and immediately asked for our orders. She ran off and came back almost immediately with our drinks. She chatted, she was warm, and she seemed to genuinely care about our well-being. At the end of the night, I can imagine she goes home happy with her day’s work.

At the Marquee, one bartender handled all of our drink orders, and she made the cocktails quite well. She memorized our drinks after the first round, so we only had to nod for the next, which really helped given the crowd. But, what struck me was the end of the night – even though we were no longer spending cash, she kept refilling our waters immediately upon the glasses being empty. She generally seemed to care that we got rehydrated and were comfortable. She was also pleasant and chatty the whole time, and danced whenever she got a free moment. Nicely done. That is exactly what I expect from a great bartender, and it brought us back to the conversation that we began in the Hudson bar.

At D-kriptik, we strive to live up the standards of the barista, bartender, and waitress outlined here – customer focused and proud of high quality work. When I interview people, I always bring up the Starbucks’ story and ask the potential D-kriptik member for their thoughts on it. Some techies seem surprised I would compare them with baristas, but that is just how we look at the world. We may state our beliefs in technology and people quite loudly, but customer service is at our core. And, walking home with a sense of pride at the hard work done during the day keeps us all happily moving forward.

Update: Wow, I got email asking where else to go and a few flames about why I did not expand on Rififi. Unfortunately, going into where to go is not a topic here; however, I will continue to reply to email messages on the topic. As far as Rififi, it was not discussed here beyond a brief blurb as it did not have a story to fit the topic. Rififi was, well, Rififi, which is to say, low key. The bartender was low key, and the patrons were low key. I tend to like low key, so Rififi is always on my recommendations list, which is why I threw it into the post.

VoIP in HBR

Tuesday, September 20th, 2005

The September 2005 issue of Havard Business Review finally wended its way to me, and it had an article on VoIP titled “Using VoIP to Compete” by Kevin Werbach. I found this noteworthy as HBR generally brings up “new” technology when a) it has the potential to significantly impact business, and b) there are real-world examples of a) to cite.

The abstract of the article can be found here, which saves me from the burden of summarizing it. The full version of the text is not readily accessible from HBR online except to subscribers; however, noting the following from the HBR landing page, I will forward full-text articles to those colleagues that request them.

HBR Landing Page Excerpt From 19-09-2005 at 11:08 PM EST

The following two excerpts from the article are examples of VoIP usage within organizations that were quite interesting.

“One Wall Street investment bank, for example, realized after the attacks on the World Trade Center that it needed greater operational resilience in the event of a disaster. It created a backup location just outside New York City, linking it to headquarters through VoIP. In a disaster, all calls can be rerouted to the new location in minutes. Without VoIP, such rerouting would have required days or weeks of rewiring and reprogramming. VoIP made it easier to add true redudancy, not just in equipment but in the continuity of business operations.”

“The hospital is integrating its patient monitoring devices into the VoIP system as well. When there’s an emergency – say a patient’s heart starts beating erratically – the system will send a customized voice alert to the proper doctors or nurses describing the problem and indicating the patient’s location. What would have been an undifferentiated call for help on an overhead paging system becomes a targeted message, informed by hospital policies, duty schedules, and individual roles. Moreover, the information generated – the sequence of calls and responses – can be captured and later analyzed in order to improve care.”

(On a side note, the article glazes over the security of VoIP, as it does anything technical being outside the focus, but Werbach does give the following example.

“Skype, for example, encrypts every call end to end, providing more privacy than any traditional phone company.”

It may, it may not. I tend to think it is no worse.

The main drawback of Skype is that it uses proprietary protocols. For example, the cryptographic protocol has not been publicly disclosed. I have read a couple of papers (1 and 2 – thanks to Hagai El Barel for forwarding the latter to me originally) and other messages on this topic, although I have seen no analysis of how Skype is actually using cryptography, except for the pointing of a finger at the use of RSA for key exchange.)

Update: Resized the captured image of the HBR subscriber message to be sized properly for the post. Click the resized image for the original, clear captured image, or just click here.

NYC BSD Con 2005 Summary

Monday, September 19th, 2005

I made it out to the NYC BSD Con 2005 at Columbia University yesterday (17-09-2005). There were a lot of interesting people, ridiculous numbers of books were given away, and I had fun. And, for what I believe to be the NYC BSD User’s Group’s first conference, things went remarkably smoothly, even with the President of Iraq on campus and one of the presenters having to cancel at the last minute.

So, Saturday morning I headed off to the BSD conference, running on little sleep and no breakfast. I had already planned on skipping the first presentation, so I arrived with enough time to sign-in and grab some coffee before the second presentation started. Since the second presentation for the conference was actually the first presentation for me, I use it as the starting point to my indexing of presentations in the following discussion.

  1. The first presentation was by Mike Lucas on Network Awareness. Despite microphone troubles, Mike could be heard clearly and he was a lively presenter. My favorite comment was that he wrote books for himself as a way to remember what he had learned – that they benefit others is just a wonderful side effect. (I feel this way about blog entries.)

    Mike organized his presentation into three main technical areas, and then went on from there to discuss interfacing with management as a techie. The three main technical areas were:

    1. Simple Network Management Protocol (SNMP) – Mike performed an overview of SNMP and recommended the tool net-smnp. During QnA, he also brought up that FreeBSD has the broadest management information base (MIB) support and OpenBSD is lagging in MIBS. For OpenBSD, he uses script wrappers to pull together the information for a MIB, such as using a script to “ps” pull out process information needed to fill in the MIB’s values.

      A good minimum of areas to monitor:

      • Network
      • Disk
      • Memory
      • Cpu
    2. Multi Router Traffic Grapher (MRTG) – Mike discussed monitoring traffic load with MRTG and showed useful (and not so useful – i.e., “do not show this to your manager”) graphs he generated using MRTG.
    3. Netflow – Mike gave an overview of netflow, discussing the three core components – sensors, collectors, and reporters. Sensors gather information and are installed on things like firewalls, and Mike pointed to software such as softflowd. Collectors collect the information from sensors, and Mike pointed to flowd and some of the components of flowtools for this. Reporters process this information to generate reports, and Mike pointed to one of the components of flowtools, Cflow, and RRD.

      Mike uses netflow for:

      • Intrusion responses
      • Identifying errant users
      • Detecting rogue servers
      • Troubleshooting

      Note: Mike has two articles on setting up netflow at OnLamp here and here.

    Mike also did a good job of discussing how a techie should communicate with his manager and people in general. I thought this was a very useful topic, although I skipped taking notes on it.

    An interesting note in this discussion was SSH over DNS and how he has easily detected it using a setup based on these tools and, of course, the knowledge that comes from knowing the networks you manage.

    Mike gave this link for pointers to his articles on what was discussed in his presentation.

  2. A substitution was made for the second presentation as Phillip Moore was not able to make it to the conference due to logistics and injuries. The topic became Domain Keys Identified Mail (DKIM) and was presented by Eric Allman. Even though it only briefly touched upon applied cryptography, I rather enjoyed this presentation. Eric clearly has his views, which may or may not differ from others, and he did a good job of identifying his opinions and the other viewpoints. My favorite quote from this presentation was the design goal of “don’t scare my mother.” It reminds me of my usual response to people saying *BSD or * GNU/Linux distribution is ready to be the average person’s desktop.

    DKIM is a protocol intender to provide sender authentication. The protocol provides the capability for sender domain authentication via digitally signatures of certain portions (as configured) of an email message (e.g., To, From, Subject, Body) using a key pair belonging to the domain. DKIM is intended to be handled by the mail server (i.e., a user sends a message, the mail server signs it using its domain private key, and then sends it along – the mail server on the other end can lookup the domain public key for the sender domain, and then verify the signature over the message.) The proposed location for storing the domain’s signing key pair’s public key is DNS, and the idea it to eventually add a structure for holding this key and querying it through DNS. There was also some discussion about how this should be possible for domain level public keys, but, given certain fields in DKIM which could in theory allow per user signing key pairs, it could very quickly have debilitating on the current DNS architecture.

    There seemed to be a little bit of confusion about applied cryptography and some of the standard cryptographic tools out there – then again, I tend to be a stickler in these areas.

    Note: The original slides that were quickly modified to make the slides for this presentation can be found here.

  3. The third presentation was by Jason Dixon Jim Dixon and this was on packet filter (pf) with Common Address Redundancy Protocol (CARP) . Jason Jim spoke very clearly and conveyed the information well. He works on the applied side of pf/CARP, so he did struggle with some of the design/implementation questions – fortunately, he was honest when he did not know something.

    pf is the firewall functionality built into current version of the OpenBSD kernel. (Before that, OpenBSD used IP filter (ipf), but there was a fall out over licensing, so the OpenBSD folks just implemented their own firewall.) There is protocol in OpenBSD call pfsync that can be used to keep the state of pf in an OpenBSD box in sync with pf on other boxes (e.g., say you have an Active firewall sever and a Backup firewall server – pfsync can keep the state of pf on the Active firewall in sync with the pf on Backup); however, pfsync does not implement failover functionality. For that, CARP was created to provide the functionality necessary to provide failover and load balancing by creating a virtual network interface shared across machines. (Cisco created a similar protocol, called Virtual Router Redundancy Protocol (VRRP), but it is owned by Cisco, so the OpenBSD’s team had to create their own. Someone later on in the conference suggested patent issues may still exist.)

    Jason Dixon Jim Dixon went on to demonstrate virtual addressing and failover with CARP. There were some difficulties during the presentation, but these were due to operator error. Jason Jim also discussed load balancing techniques using virtual addressing.

    One cool feature that will be included with OpenBSD 3.8 is “sasyncd” for failover of IPSec SA’s. The state synchronization messages can be AES-encrypted suing a shared secret key, if desired.

  4. The fourth presentation was by Jeffrey Hsu, and the topic was DragonFlyBSD in general. Jeffrey Hsu presentation felt like a race, and he made me laugh quite often with jabs at FreeBSD (and Linux) all over the place.

    The goals of DragonFlyBSD are:

    • Fast
    • Stable
    • Suitable technology (i.e., support current HW)
    • Efficiencies of scale (i.e. move much more quickly as a smaller firm. This is counter to how I have normally heard the term used – generally, efficiencies of scale refers to the benefits of growing an organization in size (e.g., buying in bulk) until it reaches the optimum size, which, if I recall, is when the efficiencies of scale can no longer outweigh the burdens of bureaucracy)

    Jeffrey discussed the general architecture of DragonFlyBSD, which branched from FreeBSD 4.10 and maintains a strong tie to FreeBSD. Essentially, the team took FreeBSD at what they deemed to be its pinnacle, and have since worked to make it according to their design goals.

    Since Jeffrey implemented many of the network code tweaks, the presentation focused in there areas when discussing implementation details of some of the features of DragonFlyBSD.

    I think some people in the crowd were upset at the FreeBSD bashing.

  5. The fifth presentation was by Bruce Momjian, and he discussed PostgreSQL. The presentation had a slow start, but, once it got going, Bruce ran with it well.

    Bruce discussed the overall development process employed by PostgreSQL and the current focus on both developing new code but also doing robust testing. Bruce discussed the interest in the private sector in PostgreSQL and the fact that many developers of PostgreSQL have been hired as experts by various companies to help modify PostgreSQL for their specific needs. This form of interaction between the open source community and private companies helps to motivate the development of open source software.

    Bruce also discussed PostgreSQL’s life, from fixing crashing bugs in PostgreSQL when the open source community first took in PostgreSQL to making sure PostgreSQL was SQL standard compliant to adding enterprise features. Bruce said version 8 was the big leap for PostgreSQL, and, after detailing some of the features in v8.0 and those coming down the pipe in v8.1, he got me interested in trying it out.

  6. My favorite presentation was also the last presentation. Marshall Kirk McKusick, whom some of you may know, spoke on the implementation changes he made to the Unix File System (UFS) during modification to support many terabyte (TB) storage systems. Kirk did a great job discussing what can be a dry topic to many and he covered a slew of technical details in a way that kept people’s attention.

    Kirk first discussed the motivations behind the modification to UFS.

    • 32-bit block pointers limited to a few TB storage systems
    • Inodes have run out of extensible space
    • Lack of other extensibility

    I took a great deal of notes on each of the tweaks, but I will not go through them all here. Some of the highlights:

    • 64-bit block pointers
    • Inode size increased from 128 bytes to 256 bytes
    • Added extended attributes
    • Added birth time (“btime”) since creation time (“ctime”) has been used as the Inode creation time, which was not its original intent
    • Dynamic inode allocation instead of complete pre-allocation
    • Some cool tweaks with underlying file system operations and interfaces, such as free space showing up immediately even if the space has not yet been freed (“df” reports the to-do list rather than actual state of the file system) and countering any issues encountered by this by co-opting process waiting on file system to perform underlying file system maintenance

    Other tidbits, Kirk mentioned that someone is currently porting Paul Reiser’s file system to BSD, and Scott Long is in the process of adding journaling to UFS2 (might be good news if softupdates don’t work well for your particular situation).

    I particularly enjoyed hearing about design decisions from 20 years ago and their impacts today.

I originally thought I would have time to attend the conference after party for a bit, but, unfortunately, I had to run downtown immediately after things let out. I was off by a couple days of when I thought fashion week wrapped up and when people would be traveling.

Anyway, I enjoyed this conference, and I am very appreciative of the efforts of all of the conference organizers and the speakers. I learned about some tools I have not yet worked with, and it great to hear about the various applications and growth of BSD. More so though, I was especially happy to learn there is such a thriving BSD community in NYC. Having just returned here from a few years down in Virginia, I knew virtually nothing about this NYC community and I will definitely start attending the NYC BSD User’s Group meetings. Thanks to everyone involved in the conference.

Update: Jason Dixon was the presenter of the presentation on pf with CARP, but I had written “Jim Dixon” in the post. Jason just wrote a comment letting me know my mistake. Sorry about the error, Jason. It has been corrected.

NYC BSD Con 2005

Thursday, September 15th, 2005

I will be taking a day off from D-kriptik and attending the New York City BSD Conference this weekend, which is being held on Saturday, September 17, 2005 between 9:00AM-5:30PM EST at Columbia University. If you will be there, please feel free to give a call to the main D-kriptik number or fire off an email to support at D-kriptik and let me know.

Information on the conference can be found on the conference’s web site, and the following excerpt is the closest I found to a description of the event besides just reading the presentation summaries.

Why would you want to come?

  • Participate, and support the BSD community
  • Network with some of the best and brightest
  • Attend presentations by prominent BSD figures
  • Sit in on lectures on the latest topics
  • Round out your technical knowledge base
  • Get together with like minded folks
  • Meet in person; put a face with an email address

The following talks look the most interesting to me, although all of the presentations seem worth attending.

  • 10:00-11:00 Michael Lucas
    “Network Management Tools to Make your Boss your Willing Slave.

    Michael will be speaking on his favorite open source network management tools and how they hook into a business environment. If he has not completed his long-overdue manuscript for his forthcoming “PGP & GPG: Email for Suspicious Bastards” before NYCBSDCon he will be committing suicide after his presentation, so catch him while you can.

  • 11:15-12:15 Phillip Moore
    “Practical Enterprise Scalability: Case Studies of Infrastructure Software Deployed in Production”

    Far from abstract and theoretical, this talk will use case studies of existing successful deployments of OpenAFS, Perl and MQSeries at a major financial institution, and provide the listener with general advice that can be applied to any number of Enterprise scale problems.

  • 1:00-2:00 Jason Dixon
    “Failover Firewalls with OpenBSD and CARP”

    Jason Dixon introduces the audience to building stateful firewalls using OpenBSD technologies. Thanks to PF, CARP, and pfsync, we are able to design fully synchronized firewalls for use in enterprise networks. The presentation begins with a background on these technologies and their purpose, then transitions into a lab environment detailing the setup, configuration, and debugging of the network. There will also be an advanced example explaining how to perform load-balancing with these same tools.

  • 2:00-3:00 Jeffrey Hsu
    “History, Goals, Objectives, and Structure of DragonFlyBSD”

    The recent DragonFlyBSD fork of FreeBSD is one of the most exciting developments in BSD development in a long time. This talk starts with the history behind the formation of DragonFlyBSD, describes its goals and objectives, and discusses how the project is structured. We next explore some of its technical advancements, such as the kernel messaging infrastructure, its network stack improvements, changes to the VFS system, and advanced multi-processor support.

  • 4:30-5:30 Keynote: Marshall Kirk McKusick
    “Enhancements to the Fast Filesystem to Support Multi-Terabyte Storage Systems”

    This talk describes a new version of the fast filesystem, UFS2, designed to run on multi-terabyte storage systems. It gives the motivation behind coming up with a new on-disk format rather than trying to continue enhancing the existing fast-filesystem format.

Of course, lets not forget this.

6:00+ Off-site After Party
Join us at [location] nearby to network, schmooze, and chat. Everyone is responsible for their own food and drinks.

Fun, fun, fun. I look forward to seeing everyone there.

Integer factoring talk today at MIT

Wednesday, September 14th, 2005

There is a talk being given today at MIT by Eran Trommer of the Weisman Institute on factoring integers with custom hardware. Integer factoring has important implications to things like the usefulness of the traditional RSA algorithm for encryption or digital signatures.

Excerpted from the Cryptography and Information Security Group: Seminars and Talks page at MIT:

Open To The Public
PLEASE NOTE Different Time And Place

Date: WEDNESDAY, September 14, 2005
Time: 4:00 p.m.- 5:30 p.m.
Place: 32-G575, Patil/Kiva, Stata Center, 32 Vassar St.
Title: Special-Purpose Hardware for Integer Factoring
Speaker: Eran Tromer, Weizmann Institute

Abstract:
Factoring of large integers is of considerable interest in cryptography and algorithmic number theory. In the quest for factorization of larger integers, the present bottleneck lies in the sieving and matrix steps of the Number Field Sieve algorithm. In a series of works, several special-purpose hardware architectures for these steps were proposed and evaluated. The use of custom hardware, as opposed to the traditional RAM model, offers major benefits (beyond plain reduction of overheads): the possibility of vast fine-grained parallelism, and the chance to identify and exploit technological tradeoffs at the algorithmic level. Taken together, these works have reduced the cost of factoring by many orders of magnitude, making it feasible, for example, to factor 1024-bit integers within one year at the cost of about US$1M (as opposed to the trillions of US$ forecasted previously). This talk will survey these results, emphasizing the underlying general ideas. Joint works with Adi Shamir, Arjen Lenstra, Willi Geiselmann, Rainer Steinwandt, Hubert K�pfer, Jim Tomlinson, Wil Kortsmit, Bruce Dodson, James Hughes and Paul Leyland.

This brings to mind a post by Lucky Green in response to Daniel Bernstein’s paper. Of course, “attacks only get better”, as Willi Geiselmann, Rainer Steinwandt, Eran Trommer, Adi Shamir, et al have demonstrated in subsequent works.

via Steve Bellovin’s post on the Cryptography mailing list.

Custom kernel build on Debian

Wednesday, September 14th, 2005

Before we begin, we recommend this page for some information on how to build the kernel on a GNU/Linux Debian system. We are just describing the steps we went through for this particular system, but that tutorial is more generic and explains some of the options in more detail.

In our previous post, we fixed two problems someone was having with Debian on the Dell Inspiron 8500. With the screen resolution clean in Gnome and surfing the web over our wireless connection, we got started on building a custom kernel.

When we installed the “kernel-sources-2.6.8″ and “ndiswrapper-source” Debian packages on the system previosuly, two files were created in the “/usr/src” directory, “kernel-source-2.6.8.tar.bz2″ and “ndiswrapper-source.tar.bz2″. “kernel-source-2.6.8.tar.bz2″ contained the source code for the GNU/Linux 2.6.8. kernel in a bzip2 compressed tar archive, and that was what we dealt with first.

To extract the source code, we ran “tar -xvjf kernel-source-2.6.8.tar.bz2″ in the “/usr/src” directory. This created a directory “kernel-source-2.6.8″. We removed the old “/usr/src/linux” symbolic link (“rm -rf /usr/src/linux”) and added a new one (“ln -s /usr/src/kernel-source-2.6.8 /usr/src/linux”). By default, virtually everything would be enabled in the kernel configuration and almost all of these enabled features would be loaded as kernel modules (i.e., not compiled directly into the kernel, but rather, compiled into their own object files and loaded as needed by the kernel). If the kernel was built this way, there would be a large number of kernel modules, many of which would never be needed for the system we were running on. For us, we wanted to configure the kernel in order to support the hardware of the laptop and potential additions to the laptop, but not everything under the sun.

To do this, we ran a “dmesg | less” to see what the output from the kernel was during boot up, including the hardware detected. With this information, we could go in and configure the kernel specifically for the system it was running on. The easiest way we found to configure the kernel was to run “make menuconfig” from the “/usr/src/linux” directory. This presented us with a clean menu for walking through the kernels features. From there, we took the output of “dmesg” and determined what could be safely enabled/disabled. For example, we were configuring this kernel for a laptop and the Dell Inspiron 8500 contains a mobile Pentium 4 with speedstep, so we wanted to turn on power management features and cpufreq. Additionally, for this laptop in particular, most of the main hardware functionality was provided by Intel components, the video card was an nVidia, and the onboard NIC was a Broadcom.

Once we had completed configuring the kernel options, it was time to build the kernel. Since this was a Debian system, we did this the Debian way. If not already installed, we needed to install the Debian “kernel-package” package. (Fired up “aptitude”, and searched for and installed “kernel-package”.) Since we were not going to be running as “root” during our build, we needed to use “fakeroot” to build the kernel image package correctly, so, if not already installed, we installed it. (Fired up “aptitude”, and searched for and installed “fakeroot”.)

Now, you may be wondering why we also extracted “ndiswrapper-source” in our previous post. Well, this kernel module was specific to the kernel it was built for but was not part of the main kernel tree, so it would not automatically be built as part of our kernel build. However, Debian made it easy for us to build this as we build our kernel. When we extracted “ndiswrapper-source.tar.bz2″, it was placed in “/usr/src/modules/ndiswrapper”, which was where it needed to be for the command we were about to execute.

Ok, so we had configured the kernel, and we were now ready to build. The following command wes what we executed to create a custom kernel image and “ndiswrapper” Debian packages.

  • fakeroot make-kpkg clean
  • fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers kernel_doc modules_image

What did this do?

  • “fakeroot make-kpkg clean” cleaned out the kernel source tree from the last build so that no conflicts or other mismatchings came up. For example, we have seens posts about there being a revision conflict detected in the Debian changelog during build when using “–revision” – this could be solved by doing a make clean.
  • “fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers modules_image” built a kernel (“kernel_image”) labeled with the version number 2.6.8.11092005 (“–append-to-version”) and created a Debian package (“make-kpkg”) for it, generated kernel headers (“kernel_headers”) Debian package (“make-kpkg”) for this kernel labeled with the version number 2.6.8.11092005 (“–append-to-version”), and built the ndiswrapper source (“–added-modules”) for the ndis kernel module (“modules_image”) labeled for kernel version 2.6.8.11092005 (“–append-to-version”) and created a Debian package for it (“make-kpkg”). All of the Debian packages included the revision identifier (“–revision”) in their filenames, which was the extent of the use of “–revision”.

These packages were all placed in the “/usr/src” directory ending with “.deb”. To install them (you must be root), we ran “dpkg -i <.deb package name>”, where “<.deb package name>” is the name of the package to be installed, and started with the kernel image. Since the software was packaged with the custom version numbers appended to their names, there was no need to put the packages on hold.

The laptop we were using used “grub” as its bootloader. When the kernel-image was installed from the Debian package, it automatically updated “/boot/grub/menu.lst” using “update-grub”; however, not everything was setup correctly for this to work properly.

Since we installed our custom ndiswrapper kernel module, we wanted to be sure all of our kernel module dependencies are configured. In order to do so, we ran “depmod -v 2.6.8.11092005″.

Our kernel was installed as “/boot/vmlinuz-2.6.8.12092005″, a System.map was created as “/boot/System.map.2.6.8.11092005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.11092005″. There was no “initrd-img” created for this kernel. To create the “initrd-img”, we ran “mkinitrd -o /boot/initrd-img-2.6.8.11092005 2.6.8.11092005″.

Next, we ran “update-grub” and rebooted, selecting our new kernel 2.6.8.11092005. All went well, but if it had not, we would have booted into an older kernel, uninstalled the packages, reconfigured our custom kernel, rebuilt the packages, reinstalled the packages, and rebooted.

We are good to go.

Two issues with Debian on Inspiron 8500

Tuesday, September 13th, 2005

We were recently enlisted to help with the post-installation issues of a Debian distribution (v3.1 Sarge – 2.4.7 kernel) of GNU/Linux on a Dell Inspiron 8500. The install went cleanly enough for the person, and everything was generally working. We were asked to fix two things, the screen resolution (15.4 UXGA) in X Windows (Gnome desktop) and to get the wireless card (Dell TrueMobile 1300) working (with WPA). Also, the person wanted a simple firewall setup.

So, in we dived. First things first, lets do an update/upgrade. We checked “/etc/apt/sources.list” just to be sure the “deb http:security.debian.org/ stable/updates main contrib” was in there, and then we ran “apt-get update” followed by “apt-get upgrade” to update the list of versions for the installed packages and then to perform the upgrade of those packages that had new versions available.

Once that was completed, we added “deb http://http.us.debian.org/debian stable main contrib” to “/etc/apt/sources.list” to increase the list of available packages to include all of those at debian.org rather than just those provided on the installation media used. Now, using “aptitude”, we see a huge set of software available for installation. Debian packages are an amazing way to install and uninstall software on a Debian system, and the application “aptitude” provides a clean interface for doing so.

Anyway, after confirming with the person there was no reason to be running the 2.4.7 kernel, we fired up “aptitude”, searched for and installed the “kernel-image-2.6.8-2-686″ Debian package, and rebooted the system with that kernel. We also installed the “kernel-source-2.6.8″ Debian package for use in the near future. This later kernel makes life easier for things like sound and network drivers.

  1. Screen resolution

    So, problem 1 was the screen resolution on the LCD. The video driver installed out of the box worked fine, but the XF86Config had bizarre settings. So, we had to update the “Monitor” and “Screen” sections of the “/etc/X11/XF86Config-4″ to have proper settings for the widescreen liquid crystal display (LCD) provided by the laptop, and we found a good sample “XF86Config-4″ for this laptop here.

    With that taken care of, we moved on to problem 2, the wireless card.

  2. Wireless Card

    Once again, using “aptitude”, we searched for and installed the “wireless-tools” Debian package. The person was using a wireless access point (AP) with the SSID of “D_dash_KRIPTIK_dot_COM” configured for WPA-PSK and providing DHCP. The wireless card was esentially built into the machine and was not going to be removed or changed, so we went in and edited “/etc/network/interfaces” to include an entry along the lines of:

      auto wlan0
      iface wlan0 init dhcp
      wireless_essid D_dash_KRIPTIK_dot_COM
      wireless_mode Managed

    You could also configure a (blech) WEP key here, but this was not necessary for our purposes. These settings might get overriden by future configuration, especially that involved for WPA, and could also be modified on the fly using “iwconfig”.

    Dell had recently issued a new driver for the TrueMobile 1300 mini-PCI wireless card, which can be found here, and we downloaded this on a machine running Windows XP. We ran this file on the Windows machine, and it automatically extracted a set of files and then ran the install program for the driver. The installation cancelled the installation as all we needed were the extracted files. By default, these files were placed in “C:\Dell\Drivers\R102320″ directory. We copied the files “bcmwl5.inf” and “bcmwl5.sys” to a USB drive for easy transport to the laptop, but this could have just as easily been a floppy disk, CD, and transferred via the network (on the Ethernet port provided by the laptop). We plugged the USB drive into the laptop and this was mounted as “/media/usbdisk”.

    Now, obviously, the drivers we just downloaded from Dell are for Windows and there are drivers released for GNU/Linux. However, with a nifty piece of software called “ndiswrapper“, we can use these Windows network drivers on our GNU/Linux machine. But, first, we need to install “ndiswrapper”. We fire up “aptitude”, search for “ndiswrapper”, and we find the necessary Debian packages for installing “ndiswrapper”. We install the “ndiswrapper-modules-2.6.8-2-686″, “ndiswrapper-utils”, and “ndiswrapper-source” Debian packages.

    After installing “ndiswrapper”, we needed to configure it. First, we installed the wireless card’s driver onto the system from the USB drive by running “ndiswrapper -i /media/usbdisk/bcmwl5.inf”. Next, we needed to find the device ID for the wireless card. We did this by running first “lspci”, which indicated that “0000:02:03.0″ was our wireless card, and then we ran “lscpi -n”, which gave the device ID of “14e4:4320″ for “0000:02:03.0″. “14e4:4320″ was what we needed to know. With this information, we ran “ndiswrapper -d 14e4:4320 bcmwl5″ to properly install the driver for the wireless card. We then ran “ndisdriver -m” and “ndisdriver -hotplug” to make tie any remaining loose ends.

    If you do not have WPA turned on for your AP or other wireless device, you could have a wireless card with a working connection at this point. However, for our setup, the wireless card was still useless. We needed one additional piece of software to provide our support for WPA, “wpasupplicant“, which is useful for cases such as these where the wireless card does not normally change or get removed. The usual routine – “aptitude”, search for “wpasupplicant”, and install “wpasupplicant”.

    We created a directory “/var/run/wpasupplicant” by running “mkdir /var/run/wpasupplicant”. We took the example “wpa_supplicant.conf” file provided with wpasupplicant and edited it to suit our needs. Essentially, we left the defaults in the example alone until “# network block” section. There, we removed all of the example entries and put in the following.

      network={

             ssid="D_dash_KRIPTIK_dot_COM"
             proto=WPA
             key_mgmt=WPA-PSK
             pairwise=CCMP
             group=CCMP
             psk="*****************************************"
             priority=1
      

      }

    Of course, the “*****************************************” should be replaced with the actual pre-shared key as configured on the AP. We placed our “wpa_supplicant.conf” in “/etc”.

    There was now a script in “/etc/init.d” that could be invoked during the various runlevels to startup the “wpasupplicant” software during boot. Before we configured this, we needed to modify “/etc/default/wpasupplicant” to properly reflect our configuration. We needed to edit “/etc/default/wpasupplicant” to include the proper options for when “/etc/init.d/wpasupplicant” was invoked. So, we opened “/etc/default/wpasupplicant”, and changed “ENABLE” to equal “1″ and “OPTIONS” to equal “-Bw -c /etc/wpa_supplicant.conf -Dndiswrapper -iwlan0″. Next, we created a symbolic link in “/etc/rcS.d” before the standard networking scripts were invoked by running “ln -s ../init.d/wpasupplicant S38wpasupplicant” from the “/etc/rcS.d” directory.

    We rebooted, and watched as “wpasupplicant” was invoked, “wlan0″ was brought up, and then “wlan0″ was assigned an IP via DHCP. Beautiful, www.google.com loaded perfectly in Firefox.

  3. Simple Firewall Configuration

    Well, we were connected to the AP, so what about that firewall? “netfilter” was built into our kernel, and “iptables” was installed on the system, which provides a way to configure “netfilter”. However, we needed a simple interface for configuring “netfilter” through “iptables”, so we decided to install “lokkit”. We ran “aptitide”, searched for “lokkit”, and installed both the “lokkit” and “gnome-lokkit” packages. We then ran “gnome-lokkit”, walked through the configuration options with the person, and we were all set.

Whew.

Remember when we grabbed the “kernel-source-2.6.8″ package a minute ago? Our next post will discuss what we did we that.