Future Tech I want to try out

In the near future, I may be allowed to have a little more quality time with my infrastructure, so when that happens, I want to be able to hit the ground running. To that end, I wanted to enumerate some of the technologies I want to be trying, since I know lots of you really like cool projects.

  1. Desktop/Laptop Management
  2. I want to work on centrally managing my users’ machines. I already mentioned rolling out machine upgrades in flights. That way all I can distribute all machines pre-configured, domain authenticated, really take advantage of some microsoft-y technologies like Group Policy object to install any additional software on the fly. I want to do network-mapped home directories, as well, which I can only do on those users who have machines which have been added to the domain. I’d also like a little more full-featured computer management solution. I’m really sort of leaning towards (at least) trying Admin Arsenal, who did a guest blog spot last week. I’ll have to do some more evaluating and try some test runs to see how it goes.

  3. DRBD
  4. DRBD just sounds like a cool technology. Essentially you create a clustered filesystem, even though both machines aren’t connected by anything other than a network. The scheme is called “shared nothing”, and from what I have read, the filesystem is synced on a block level over the network. I can definitely see how it would be valuable, but I have lots of questions about what happens during network outages and the like. Ideally I would be able to setup a lab and go at it.

  5. Puppet
  6. Puppet was the darling of the configuration management world for a long time. According to the webpage, it translates IT policy into configurations. It sounds like alchemy, but I’m willing to give it a shot, since so many people recommend it so highly. Speaking of people recommending something highly….

  7. ZFS
  8. Somewhere on the hierarchy of great things, this is reputedly somewhere between sliced bread and..well, pretty much whatever is better than ZFS. That’s a long list, no doubt, but reports are fuzzy on where bacon stands on the scale. In any event, if you’ve recently asked a Solaris user what filesystem is best for…pretty much anything, chances are good that they’ve recommended ZFS. If you’ve offered any resistance at all, you’ve probably heard echoes of “But….snapshots! Copy on write! 16 exibytes!”. I suspect that its allure would probably lessen if it were actually available on Linux instead of being implemented in FUSE, but that’s probably sour grapes. And in order to actually try it, I’m going to need to try…

  9. OpenSolaris
  10. All the fun of old school Unix without any of the crappy gnu software making us soft and weak. OpenSolaris became available when Sun released the source to Solaris, and a community sprung up around it. Learning (Open)Solaris is actually pretty handy since it runs some pretty large scale hardware and apparently there’s some really nice filesystem for it or something that everyone is talking about. I don’t know, but I’d like to give it a shot.

How about you? If you had the time, what would you want to spend some time learning?

  • Greg

    Minor nitpick … it's "DRBD" (Distributed Replicated Block Device :) ). It's a really great product — as long as you're aware of the implications and failure modes. I have plenty of 'em in production.

  • Some Guy

    I had less luck with DRBD, but, we were trying it combined with ZFS at the time (about, um, a year ago?). I'd still rather have something else deal with the replication, maybe NetApp or something.

    ZFS really IS the bees knees, and it's the little things I like a lot.

    1) Windows admin goes 'Can you give me 200g of storage for, say, writing archive tables to?'
    2) One 'zfs create -V' later, I reply with "here's the iscsi id. have a lot of fun"
    3) Windows admin asks 'um, how do I snapshot that?'
    4) About 10 seconds later "Done. Lemme know if you need to roll back"

    I also use it a LOT LOT LOT for:
    1) We need package 'X' built for version 'Y'
    2) Ok. Launch zone. Build package. From global Zone, copy package away. Halt zone. zfs rollback. My nice sexy build environment is pristine again.

    The documentation on the zfs command is, to be honest, occasionally crap, and I think the permissions granting system needs work still (give users the ability to snapshot their own home directories, for example), but it is NICE overall.

  • Matt


    Ugh. Thanks for letting me know. I fixed it. I posit that DRDB would have been a cooler name, because then they could go by "Dr Database". Or something.

    @Some Guy
    DRBD + ZFS = buzzword bingo win! ;-) I really am looking forward to learning it. Whenever this many people talk about one thing in a positive manner, it's either great or imaginary. Since I suspect that ZFS exists, I'll give it a shot. Thanks for the comment

  • David Magda

    I think DRBD is Linux-specific, however, if you're going to play with (Open)Solaris and ZFS, you may want to also check out AVS:


    It's the Solaris-equivalent to DRBD. It used to be a commercial product, but an open-source version is now available for use with OpenSolaris.

    There's also QFS:


    It allows multiple machines to mount the same file system and both read and write to it. Traditionally it's been used on SANs, but a shared SCSI chain could be used and probably iSCSI as well.

  • mrsvan

    If you have an interest in testing DRBD, you may want to check out my MySQL HA project on Launchpad…

    It is still in pre-alpha stage, but the goal is to make a DRBD implementation very simple on Debian.


  • Matt


    I'll have to add that to the list. I'm not limiting myself to experimentation with *Solaris, but really just to try cool things that I don't have the chance to now.


    Neat! thanks for the link, I'll check that out!

  • Andrew

    You compare something to bacon with any sort of doubt?

    I'll remember this in your review…

  • Kamil Kisiel

    If you've got a Linux type environment, I recommend you try Bcfg2 as well as Puppet. I may be a bit biased since I'm a frequent contributor to the project, but I found it to be better than Puppet. Plus it's written Python, which is typically installed on most servers, unlike Ruby.

  • Matt


    Cool, thanks for the link. I'll take a look at it.

  • rmm4pi8

    I wonder what issues people are having with DRBD? I mean, like any HA technology, it's definitely in the "handle with care" category both in complexity and the importance of getting it right, but I have it in production for 3 different MySQL master pairs, and it's just been fantastic. Between moving datacenters, load balancer problems, and disk failures we've done over a dozen planned and unplanned live failovers with nary a hitch.

    As for puppet…I was late to the game only discovering it about 10 months ago, but since then I've written 17,000 lines of puppet config, so you can count me in as a believer. I think the secret to making puppet work as someone other than a professional consultant is to begin simply, and take advantage of the power only as you need it. The file serving is the simplest, so if I have only two versions of a config file, I'll probably just serve both rather than using a template, but once there are five I refactor. For me, that's been the balance between using the power of the tool/Don't Repeat Yourself and not getting hung up in a bunch of complexity around modules and facts just to get started. Don't feel like you have to tackle all the pieces right away. For a while I was just fileserving /etc/passwd instead of using the users module. Now, I'm glad I switched, and the users module is very powerful, but I don't regret starting with the simplest possible benefit and growing comfort as I went. I'm about to embark on external node storage and scaling puppet itself, so more challenges lie ahead, but it's by far the simplest tool in its class I've ever seen.

    With OpenSolaris, all I can say is that I'm jealous. DTrace, Zones, and ZFS are all super-cool, but I just haven't been able to justify the time away from Linux.

  • Matt


    I'm not sure what the problems people have had with it, but I have no doubt that if they're possible, they'll happen to me when I implement it ;-) I'll make sure to write about any experiences I get with these technologies.

    17,000 lines of puppet config is _a_lot_. That's pretty amazing. You wouldn't be interested in doing a guest blog talking about starting a puppet config, would you? If not, no worries, I just thought that you, with your experience, are really someone my readers would like to hear from!

    Thanks a lot for the comment. I can't wait to try these things out. Soon I'll be able to tell everyone what's changing to let me do it, I hope.

  • therek

    +1 for Bcfg2 as Kamil Kisiel wrote.

    As for your OpenSolaris comment:
    "All the fun of old school Unix without any of the crappy gnu software making us soft and weak."

    In OpenSolaris GNU tools are in the PATH before Solaris native tools. Shame, I know :)

  • Matt


    Well! Shows how much I know :-) This is just a sign that I need to learn more about it ;-)

  • Pingback: Progress report and vacation next week | Standalone Sysadmin()