Archive

Archive for February, 2009

Vyatta Initial Impressions

February 26th, 2009

I’m part-way through the major overhaul of my home network (hosting this blog and everything else jasonantman.com) that I’ve been planning for quite some time. The current hardware is… uh… currently… described on my Hardware page, but I soon plan on ditching the wiki and moving to a CMS for my entire site.

Anyway, so far I’ve decommissioned my aged HP ProCurve 2424M switch and replaced it with used but less-aged Cisco 2948G from Horizon Datacom (purchased on Ebay). Quite an upgrade. In order to handle network backups a little better, I’m also adding a Cisco 4912G 12-port Gigabit (GBIC) aggregation switch for the administrative/backup VLAN – though this was purchased via ebay from RedApe Technologies in PA. The switch came with 12 1000BASE-SX GBICs, and I plan to do a mix of copper (1000BASE-T) where it’s already available (onboard NICs) and 1000BASE-SX where there’s enough room in the box for a card.

On the hardware side, I also have 2 new boxes – a set of HP Proliant DL360 G2’s from MJS Global, who I’ve done business with before. The prices were great, and though one of them showed up with a faulty temperature sensor that prevents boot, MJS has been wonderful and is shipping me a replacement motherboard. One of the boxes will be running Vyatta (vee-AH-tha) VC5 router/firewall software, and the other will be a new services box running internal DNS, DHCP, NTP, and whatever else.

On the hardware side, I’m also planning some extended downtime a few weekends from now, when I should finally have a 42U rack to replace the Sears shelves my equipment is now on. It’ll be a fun-filled evening of racking equipment and re-patching everything. Also, hopefully within a few weeks, I’ll be moving my WAN pipe from Verizon FiOS residential to Optimum Business, which is essentially re-packaged residential but provides 5 static IPs, no blocked ports, and 30 Mbps down/5 Mbps up.

Vyatta

When planning this upgrade, I think I looked at every open source router package out there, as well as some of the lower-end or older Cisco models. I’m currently running IPcop, which does everything I need except it doesn’t handle multiple WAN IPs, and all configuration is via a web interface – which means every time I want to make a change remotely (and during the week I’m not home) I have to forward HTTPS over SSH. After doing an extensive feature comparison, I ended up narrowing it down to a relative newcomer – Vyatta. Though I don’t know how much of it is marketing hype, they are targeted squarely at Cisco, and provide relatively enterprise-level features; a JunOS-based CLI, BGP, OSPF, and all of the other important stuff.

Yesterday I attempted an install of Vyatta CE 5 Beta on one of the DL360G2’s. The only real problem that I found was the install script doesn’t support CCISS drives, as found in the Proliants, but a few manual hacks to the script fixed that. By far the best thing about Vyatta is it’s based on vanilla Debian Lenny, and full root shell access is available, so modifying the install script – or even adding non-Vyatta packages – is a cinch. I haven’t really played around with it too much, but it appears to be a wonderful mix of Linux and an enterprise router CLI. While root has a full BASH shell, and the Vyata commands are all done as shell aliases (so users still have access to shell primitives and OS commands), configuration is accomplished via a JunOS-like command set. You still get “commit” and “rollback” in config mode, and can still do fun things like save and load configs to/from tftp, ftp and http. On the other hand, I doubt I’ll do config backups that way since I can just use scp or sftp.

The Vyatta box will probably go home this weekend, and get hooked up to the network for config-only use (and I can always get in via iLO on the hardware) and hopefully come up sometime in the next few weeks.

At this point, the most daunting task is figuring out how to get all of the existing links to my site to work – since jantman.dyndns.org will be legacy, and most of the site structure will probably change to use name-based vhosts. Lately I’ve been trying to use the real subdomains in all of my public links, so the transition (planned for a while) will work, but I’m sure there are still plenty of links out there that will need dealing with (maybe keep port 10011 serving HTTP with a massive mod_rewrite script to redirect to the right place???), as well as checking everything on the web server to make sure there aren’t any absolute URLs (like WordPress).

Projects , , ,

ROUThost DNS problems; GoDaddy and Security through Obscurity

February 25th, 2009

The external-facing web site and (internal use) mailing list for the ambulance corps is hosted by ROUThost. Not my choice, it was inherited. ROUThost, first off, appears to be a fly-by-night hosting provider that just buys a few boxes in a colo facility. I should have known to raise a stink when they say you need to fax a copy of your driver’s license to get SSH turned on, and that you have to agree – in legalese – not to mess with anyone else’s configs. Well, last night, DNS for the site went down. As in nothing, wouldn’t resolve at all. I submitted a ticket online for ROUThost’s “24×7″ support – by the way, they don’t have a phone number, only an online ticket form. After 2h 34m 40s of downtime, the issue resolved itself and I downgraded the ticket from “critical” to medium. Now, 11 hours later, it still hasn’t been replied to. And my emails to support and management – 2 hours ago – are unanswered.

Once the problem started, I knew the yearly contract with ROUThost was a bad idea – even at $35/year USD. So, given the great experience I’ve had with them as registrar for my myriad domains, I took a look at >GoDaddy’s site. They offer shared hosting at around $4/month (for shared on a Linux box) and are currently offering some deals, so I figured it would be a good idea. I know and trust GoDaddy’s support, and have had an account with them for quite some time.

The ambulance corp’s web site, hosted through ROUThost, does essentially three things; provide a minimal web presence (the whole web root is probably < 1Mb minus the photo albums), five e-mail forwarders for the officers and a GNU MailMan mailing list for internal business. Unfortunately, I couldn’t find anything in their “features” list mentioning MialMan or any other listserv, or even what MTA/MDA they run.

I put a call in to GoDaddy “Sales/Support”. The poor guy had never heard of MailMan, but asked “one of the hosting guys” and was told it would only be supported on dedicate hosting accounts. Not exactly financially feasible for a mailing list with 30 subscribers, maybe 2 messages a day, and a monthly HTTP transfer of under 20Mb. I was told their shared hosting packages don’t include any mailing list/listserv software, though they include every CMS and language known to man. Hell-bent to get away from ROUThost, I then asked if they ran an MDA that supported piping mail to a command, as can be done with .procmailrc. After a brief hold (not to sound cynical, but I’m sure the gentleman was looking up “MDA”) he came back on the line and told me they didn’t. I then switched to problem-solving mode and asked what MTA and MDA they were running. Another brief hold, and I was told “I can’t tell you that”. Speechless for a moment, I asked what that meant; “we don’t give out that information”. Just about ready to begin explaining SMTP headers, I gave up and thanked him for his time.

Ok, so Sales probably doesn’t understand SMTP headers. I’d considered trying to find mail from a GoDaddy Linux hosted box and check the headers, but I figured I couldn’t do that before the call ended. So, now I’m left with a dilemma. ROUThost is not, in my opinion, reliable, and their support is flat-out nonexistent. 11 hours is far too long to wait for a reply to a “critical” ticket when someone claims 24×7 support. However, by previous experience, GoDaddy would be my next choice – but not only do they ot support mailing lists – arguably the most used feature of our current hosted account – but they won’t even tell a customer what MTA they’re running. I’m too let down by this to telnet 25 on one of their boxes and see what happens.

So what’s left? I guess waiting until (hopefully some time within the next few weeks) I upgrade to Optimum static IP at home, and consider running it all there (and hope mains power never goes out for more than 30 minutes?)

Ideas and Rants, Projects, Reviews , , , , ,

Online Exams and Reality

February 17th, 2009

A friend recently showed me the syllabus for one of her classes, which is partially given online through the Sakai course management system. At the bottom was a section on course policies which stated, in part, that the “Academic Integrity policy is in full effect”. Apparently, this professor is giving online exams in Sakai. The policy goes on to state that not only is collaborative test-taking not allowed, but also that use of any resources (including a textbook) is not allowed. The policy states that use of electronic resources (”a second web browser”) is also not allowed, and that the course management system includes “features” to prevent “cheating” – enumerated as a time stamp for every answer.

To me at least, this shows not only an unrealistic outlook, but also a horrible lack of understanding about technology.

  1. Does this professor actually expect that he can have students taken an exam at home, on a computer, and none of them will Google an answer? If so, he should take some steps to actually prevent such actions – like having the students take the exam in a proctored environment. If not, what is the purpose of this intimidation?
  2. I know I’m not a programming wizard, but if someone can tell me the algorithm to determine whether or not a student is cheating – based solely on their answers and the submission time of each answer – I’d really like to be enlightened.

If professors want to administer exams online and prevent students from using any outside resources, it seems to me like the only way to realistically do this is to setup a human-proctored computer lab (perhaps University-wide at a number of locations, available for members of any class) that allows access only to HTTP/HTTPS for the course management system and nothing else. All the human proctor would have to do is sit in the room and make sure students aren’t looking in textbooks or conferring with each other.

Higher Education , ,

Why DRM is bad for consumers

February 10th, 2009

While some people whom I greatly admire have stronger feelings than I on the subject, and many others, I felt the need to share some thoughts on DRM this morning.

Here at Rutgers, we had been promoting Ruckus for music downloading. The idea was that if you go to Rutgers, you get to use their service for free and download your music. I’ve never used it. Even if their software had worked with Linux, it’s still so badly DRM’ed that I couldn’t even burn the music to a CD. Being an old-fashioned person who has a regular old non-MP3 cd player in my truck, what good would that do me?

So, today Ruckus just shows this:
Ruckus shutdown graphic

I’ll admit it, I’m not the least bit sad to see it go. And not just because it was Windows-only at a time when Linux is gaining in popularity and MacOS is all-out exploding. What was my real problem with it? The DRM. What good is a bunch of 1’s and 0’s if I can’t use it the way I like? You couldn’t burn Ruckus music to CD, and I doubt you could use it on my ancient Sansa 512MB MP3 player either, as it doesn’t support DRM (and runs Linux).

So what’s my final thought? From TechCrunch.com:

We’re told that music that has not passed its “renew date” still works, but that music that has expired will no longer work because the DRM licensing server has apparently shut down.

If DRM wasn’t bad enough to begin with, the music you already have will just stop working… because the original distributor isn’t there anymore to tell it to work.

Higher Education , ,

My Dream Network

February 7th, 2009

On the same thread as the last post, some thoughts on my ideal network, or the hosts on that network:

  • One “gold master” installation/kickstart file of a single chosen distro, with a base set of packages, including site-specific packages. (or something like this implemented in a configuration management system)
  • All new installations performed over the network in an automated fashion, and from a local repository.
  • Software updates are automated (either through a configuration management tool or something like the behemoth I talked about here and pulled from a local repository (perhaps one which mirrors the mainline repos, but only downloads a package the first time it’s requested?).
  • Puppet or CFengine on each machine. Better than just having them is having each machine automatically added when it’s created. Even better yet would be to have Puppet or CFengine combined with something like Cobbler, so I can define a new machine in {puppet|cfengine}, list its’ MAC address, then netboot the box and come back in a few hours to have an OS installed, packages installed and the machine configured, monitored in Nagios, monitored for security and backed up.
  • Tripwire or some other sort of security software, as well as centralized logging and auditing, on every box.
  • A small number of additional “package groups” to add to the “gold master” via config management – something like “web server” (Apache2, PHP, MySQL, log analysis for them, etc.), “development server” (CVS, debuggers, etc.). These would also update the backup system to include appropriate directories, update Nagios configs, etc.
  • A good way – if even a human making notes in a per-machine text file – of tracking the “little stuff” like that one cron script that makes everything work right, the location of that hacked-together Python script, etc. A way to easily remember the things needed to recreate a box which aren’t found in rpm -qa or any obvious overviews.
  • Bacula or AMANDA setup to backup every box, perhaps with some sort of template system for server types – every machine gets /root and /etc backed up, but web servers get /srv/www and mail servers get /var/mail.
  • Nagios setup to monitor everything logical on every box. Perhaps this would use a configuration management engine to handle Nagios configs, so that for example if any Proliant hardware is used, {config management program} will figure this out, install the HPASM packages, put the appropriate check scripts on the box, and update the Nagios configs. Likewise, adding Apache to a machine should cause it to be monitored in the Nagios configs.

Unfortunately, as I’m not independently wealthy, I don’t have the time to quit my job, wipe every machine I own, and start from scratch. But it sure would be nice to be able to, one day, start a server farm from scratch and be able to implement some of these cool things…

Ideas and Rants , , ,

Community Datacenter

February 7th, 2009

I’ve been planning a lot of administrative work lately… I have a few machines that need OS upgrades, my backup system is barely functional (it needs both a new, large disk and a configuration overhaul), and I’m planning a switch to static IP service – which means not only a new router/firewall to design, configure and monitor, as well as moving some services previously run by IPcop over to a dedicated box, but also finally adding three IPsec VPNs, monitoring them and tunneling all sorts of stuff over them, and reconfiguring all of my DNS, finding any hard-coded URLs, and a slew of other projects.

So this got me thinking. While there are a number of reasons why I run such a complex network at home (mainly including maintaining my presence on the web and my email, providing temporary hosting for freelance work, the convenience of file access from anywhere, the breadth of administrative experience it gives me, and a way to test new technologies) there are some parts of it that I just don’t like dealing with. I’ve never been a really network-centric guy, and the idea of having to setup a router/firewall (I’m going with Vyatta as it seems to be the only thing that will deal with the complex configuration I want) for all this just to get 5 static IPs seems a bit much. Not to mention there’s just too much running on all those boxen (8 at home, 2 at school, plus 3 others at 2 other locations) for me to keep a handle on all of it and still be a full-time student, work 30 hours/week, and do freelance work. Something’s always bound to get ignored – sometimes backups stop for a week, sometimes Nagios goes haywire, and sometimes Cacti stops graphing for a month before I notice it.

The biggest thing I learned from running all of these systems for personal use is to start everything consistently and with a plan. My oldest box in semi-production is running SuSE 9.3, installed somewhere between April and October of 2005. It was ignored for so long (a period when it wasn’t being used for much) that I now can’t even perform updates, as the update sequence is virtually impossible to accomplish. Then again, re-purposed desktops shouldn’t be in “production” for 4 years. Anyway, perhaps the biggest lesson in trying to deal with all of this is the importance of consistency. Not just attempting to standardize on one distribution, but also making a local image that includes the standard packages, configurations, and other important stuff – like the Nagios user account and local plugins and maybe even the public SSH key of the Nagios box. Even better would be a configuration management system like Puppet or CFengine, or even manually keeping all of the distros updated to a common version.

But, I digress. The real point of this post was supposed to be a simple idea: I have all of this running at home, and I know quite a few IT people who have a similar setup at home or at work, or have considerable resources at a hosting/colo facility. So, why not start a “community datacenter” project? At home I have to do everything from backups to firewall and router administration to security. I’d be much happier just handling network/service monitoring, log analysis, and some tool and web scripting. I know a few Cisco-heads who run their “home” LANs on chassis switches, but find it such a pain to reconfigure Apache or run a monitoring app. I’m sure someone’s thought of this in the past, and probably tried it, but why don’t some guys (who can be trusted) get together, find some colo space (or anywhere with power and connectivity) and start, essentially, a co-op data center? Assuming you could find a large enough circle of trusted friends, I’m sure you could find someone willing to volunteer every service needed – from network engineering to backups, monitoring, and security – in exchange for some rack space and connectivity, or even a virtual host. I know I’d opt in any second – or even let someone throw a box in my basement in exchange for someone to help read through logs or setup a HTTPS VPN, if it weren’t for the archaic equipment I’m running.

Just a thought…

Ideas and Rants ,

My Birthday!

February 6th, 2009

I happened to be working with some timestamps today and noticed that we’re starting to get into territory like 1234094400. So, being the geek that I am, I wondered when we’d finally hit 1234567890. The answer is 2009-02-13T18:31:30-05:00, which happens to be 18:31:30 on my birthday. Yay!

Personal ,

How To Wipe a Bunch of Machines Quickly

February 3rd, 2009

Updated 2009-03-05, see bottom.

At work the other week, we decommissioned 24 old desktops – Dell GX280’s that were used in the student labs as print release stations. They didn’t have anything sensitive on them, just Windows XP, but with licensing and all we have to wipe Windows off of them before surplussing them. Since there were 24 of them, it wasn’t exactly going to be the quickest task. Moreover, the GX280’s we used don’t have any removable media drives.

A few people mentioned Darik’s Boot And Nuke (DBAN), which is a bootable Linux distro (CD or floppy) aimed at wiping all of the fixed disks attached to a machine. While they do offer an “Enterprise” version that supports network booting (and logging wipe verifications to a central machine), the pricing isn’t exactly favorable for a small project (or something that just needs Windows to go away, not a DoD-grade 7-pass overwrite with random data). Between the lack of a CD drive and the apparent need to select wiping options at boot, this didn’t seem to be the best method for me.

Luckily, with a little googling, I came by the Cobbler project, a ready-to-run install server aimed at automating network-based OS installation. It turns out that Cobbler has a wiki article on system retirement that deals with using Cobbler to automate a network boot of DBAN. Cobbler takes control of DHCP and TFTP, boots the machine(s) to a PXE boot menu, and allows selection of one of the cobbler “profiles”.

The general procedure is something along these lines:

  1. Get the DBAN iso and grab the .ima image off of it. Loopback mount it.
  2. Copy the initrd and kernel into /opt/cobbler/dban as initrd.img and vmlinuz, respectively.
  3. Assuming you have cobblerd running (cobbler check), add a Distro for DBAN: cobbler distro add --name=DBAN-1.0.7-i386 --kernel=/opt/cobbler/dban/vmlinuz --initrd=/opt/cobbler/dban/initrd.img --kopts="root=/dev/ram0 init=/rc nuke=dwipe floppy=0,16,cmos"
  4. Add a Profile for it: cobbler profile add --name=DBAN-1.0.7-i386 --distro=DBAN-1.0.7-i386
  5. cobbler sync

Assuming all went well, when we PXE boot a machine on the same LAN as the Cobbler system, we’ll get DHCP and a PXE boot menu which will list DBAN-1.0.7.i386 as one of the options. On some of the GX280’s that I did, I had to go into the BIOS and enable PXE boot (or select PXE from the BIOS boot menu). Now, when DBAN boots, we’ll get the standard dmesg output and then a selection screen allowing us to pick a wipe type (I used the single pass all zeros for just getting rid of the old OS) and select which disks to wipe. If you use the default wipe, just press “space” to select all disks and then “F10″ to begin the wipe.

This process allowed me to wipe 7 machines at once (8 port KVM, 1 port for the server). With a better KVM or (even better yet) a totally automatic system as described below, it would essentially be limited to whatever the server and network hardware will handle.

To add a little more automation, we can run cobbler system add --name=default --profile=DBAN-1.0.7-i386 which adds a default profile to Cobbler, saying that any machines with MACs not specifically assigned to a profile should boot the DBAN profile, and bypassing the PXE boot menu.

WARNING: what follows will setup Cobbler and DBAN to automatically wipe all PXE-booting devices without ANY human intervention. Use at your own risk and, for God’s sake, don’t plug your server into a production network (I recommend this only in a lab environment with a dedicated switch, all machines in one physical area, and no possibility of getting on the same ‘net as production machines).

It’s theoretically possible to totally automate this setup. According to the DBAN docs, it will also accept kernel options (kopts) that effect how dnuke works – specifically, --autonuke to tell it to wipe without human intervention and a method option such as --method=zero to select the wipe method. This means that if we PXE boot with kernel options set to nuke="dwipe --autonuke --method=zero" we should go straight to the dwipe utility (the heart of DBAN) and automatically wipe all disks by writing zeros once – without operator intervention. Unfortunately, there’s a bug in the current (1.4.0) Cobbler which prevents quote-encapsulated strings in kopts, meaning that we can’t set one kernel option to a string with whitespace as needed here. If this bug is fixed, it should allow this process to work without any operator intervention, assuming the clients will PXE boot.

Updated 2009-03-05 I haven’t tested it yet, but apparently the Cobbler bug preventing complex kernel options has been fixed. The fix should be included in the 1.4.3 release and is currently in the development tree.

Tech HowTos , , , , , ,

Truck Wiring and Lighting – Part I

February 3rd, 2009

As mentioned in my Custom Truck Console post, since my truck was stolen and now recovered (with all of the emergency equipment stripped out – weird) I’ve got to start from scratch. Since I finished the console, I’ve started work on redoing the lighting. The first grueling step was to check continuity of the existing wiring (what was left of it), strip out everything that didn’t work, and rehab what did. Then I did a few pulls, mainly a giant pull from the console to under the hood of six 16-ga wires and three 12-ga, along with a massive run of 6-ga welding cable direct from the battery (with a circuit breaker) to the console.

There’s a thread covering this install over at elightbars.org as well as a thread on the previous (original) installation.

This is part 1 of (hopefully only) 2. The list of what’s installed so far is:

  • Custom console.
  • Galls SE082 switch box – 3-position slider, 5 on/off rocker switches and one on-off-(on) rocker switch.
  • Radio Shack Pro-433 scanner, hopefully to be replaced by a Icom F5061.
  • B/B Whelen Dual Avenger above rearview mirror.
  • Unitrol 80K air horn (siren wires not connected)
  • 2x Sirennet 100W speakers mounted in front bumper.
  • 2x B/B Whelen LIN4’s on 10-75 Lighting front license plate bracket.

The console with equipment mounted in it:
console

Dual Avenger (B/B) on headliner bracket above rearview mirror – it just fits:
dual avenger on headliner bracket

Avenger from the outside:
avenger from the outside
avenger from the outside, lit

10-75 Intersection Bracket behind front license plate. B/B LIN4’s:
10-75 intersection bracket

SirenNet 100W speakers behind front bumper:
speakers in front bumper

Coming next:

  • 4x (!!!) blue Whelen 500 Linear Super LED’s in front grill, mounted with chrome flanges.
  • B/B LIN4’s on front running board mounts.
  • Blue LIN3’s on rear license plate bracket.
  • Some sort of lights in the rear window – if I can afford it, blue/amber Whelen 400 Linear’s (6-over-6) independently switched.
  • Icom F5061 VHF mobile.
  • VHF antenna, either roof mount or mounted in a stake pocket.

Vehicles , , , , ,

Custom truck console

February 3rd, 2009

I’ll keep this post relatively to the point (the original full story is on eLightbars.org here and here). My 2006 Ford F-250 CC XLT was stolen in September, 2008. It was recovered about a month later, after Geico said they’d pay out, and after I’d bought another vehicle. Anyway, it came back from the body shop about 2 months later, and it was time to begin customizing it again. The main parts of the project were wiring and installation and building a custom console…

My main inspiration was some of the custom consoles done by places like Odyssey, though I wanted something carpeted (hopefully a close match to the factory interior). The main idea I was working off of was this one from Odyssey:

Odyssey Excursion console

The general idea was to have a replacement for the factory console which would allow mounting of a radio, emergency lighting controls, and a few other things while not sacrificing storage space. The specific requirements that I came up with included:

  • Mount over the transmission hump more or less where the factory console is, forward to the dash.
  • Allow access to the pull-out cupholders in the dash and not impede access to any controls.
  • Fasten to the floor using only the four factory console bolts.
  • Allow mounting of at least one radio, one switch box, GPS and scanner.
  • Radio and switch box should be mounted using the Jotto Desk faceplates that I had from the CVPI console.
  • The real clincher that prevented me from using a stock console: Have a large storage compartment comparable to the factory console.
  • Provide a set of rear cupholders.

I spent some time over the course of three days or so measuring the console area of the truck and drawing out my initial plan in CAD (specifically the demo version of QCAD for Linux – regrettably not Free software). Once I had the plans drawn up and was satisfied that the angles and measurements were within acceptable tolerance, I made a full-scale prototype out of foam core board. With a little shaving of the corners, I managed to get a relatively good form and transferred it to ½" cabinet-grade luan plywood. It was a bit difficult with only a jigsaw, but worked out relatively well. While I can’t seem to find any pictures of the foam core, here are some of the wood form being assembled and the test fit in the truck:
first assembly and test of console
first assembly and test of console
first assembly and test of console
I’d originally been a bit worried about the structural integrity, but I found that by clamping the corners, pre-drilling and securing them with aggressive wood screws at approximately 1 screw per 1.5 inches along the joints, the plywood held together fine.

After testing the fit and checking that the four factory bolt holes lined up correctly (which they did, and also held the console quite securely), I pulled it back out and started the process of carpeting it. I bought 2 yards (76 x 72 inch) of color #8078 “Dark Grey/Quartz” plush cut pile automotive carpet from StockInteriors.com, for about $80 with shipping. It turns out that the color isn’t an exact match to the factory carpet (I got 6 sample squares from them and this was the closest color) but it’s a good medium between the carpet and upholstery.

Planning for how to cover this wooden behemoth with carpet took quite a few hours, and short of making it into a week-long job of sewing, I decided to wrap the sides and back with one piece, folded over on the bottom and top edges of the storage box, then use separate pieces for the top of the console and the front (which would be adjacent to the dash and mostly hidden from view). I started off with a plan to use 3M Super 90 spray adhesive, on the advice of an ELB member. Unfortunately, I could only find Super 77.

Prior to carpeting, I had to get the equipment mounting openings down to about 8.5" for the 8.75" Jotto faceplates. I cut some excess luan plywood down into 2" wide strips and then cut them to length for the openings, sandwiching about three together with Liquid Nails and then mounted them vertically on the sides of the console.

Carpeting the console at 2 AM probably wasn’t the best idea. I looked at how the cut edges of the carpet would meet and the corners, and decided I’d need some sort of edge molding to make it look good – preferably black powder coated aluminum, somewhere around ½" legs. As such, I decided to forgo most of the glue and stapled the carpet at the edges, planning to cover it with molding. Ok, I lose a few points for that one. The last thing to go on was the carpet on the front and top, which I glued with Super 77 and also stapled on the front (where it can’t be seen). I cut X-shapes in the mounting areas and folded the carpet down, stapling it to the inside of the console, and cut a slit in the front for wiring. The glue didn’t seem to hold on the narrow parts of the top/mounting area, but once faceplates were screwed in it was fine. The faceplates are just held in with screws into the vertical wood strips placed on the sides of the opening.

Top view of the console, mounted in place, with the unfinished storage box.
top view of console

Equipment mounting area:
console equipment mounting area

View from the driver’s seat:
view from drivers seat

Factory cupholders extended with just enough clearance to work:
factory cupholders open, barely

Staples around the edges, intended to be covered with molding. They’re really not that visible unless you make a point of looking at them (given their placement). Red handle is a 100A cutoff for the main battery lead, with a removable handle.
staples around edges and battery cutoff switch

The weekend after console fabrication, I started wiring. Here’s the relevant parts involving the console.

Semi-finished console with equipment mounted. Front-to back, RAM magnet mount for GPS, Radio Shack Pro-433, Galls SE082, nifty Jotto storage tray.
equipment in mounted position

Wire routing in loom from the console to under the dash
main wiring runs

Rear of console – Jotto cupholder and charger for Streamlight Stinger 75014
rear of console

Still to be done:

  • Most of the wiring and installation.
  • Lining the storage box with something, probably toolbox drawer liner.
  • Making a cover/lid for the storage box.

Vehicles , , , , ,