User Tools

Site Tools


This is an old revision of the document!

BALUG todo list

in approximate priority ranking - notes first

  • Notes:
    • This is not a complete/current list
    • higher/highest priority towards the top
    • lower priority items may proceed before higher items depending on resources and if not dependent upon higher priority items
  • system(s):
    • restore (most) all functionality BALUG had on the <=2009-11-11 VIP on shared tower box to the balug Xen domU, still to do:
      • finish rounding out appropriate redirects (critical ones done, but many others remain to be done)
      • disable temporary testing stuff(?) (e.g. /env)
    • send out relevant communication(s) once the above is sufficiently complete (most notably need to update webmaster how-to stuff, as it's changed a fair bit).
  • more wiki page updates:
    • webmaster "how to" and such (work-in-progress)
    • sysadmin "how to" and such (mostly pending)
  • speakers/presentations
    • line up more speakers/presentations
    • get more volunteer(s) actively working on this

Caution - much of the material on this page below this point is rather out-of-date

general todo

  • Get (more) detailed information (text blurbs, etc., both short and extended) for upcoming confirmed speaker engagements
  • update website with the above
  • (hosts transitioning to new hardware box!
    • remote management/setup: KVM over IP? (Michael Paoli attempting to get resources for that; Cced Jim Stockford on communications).
      • obtained one remote KVM device 2007-11-01, have another remote KVM devices pledged to us/SF-LUG - need 501(c)(3) EIN for the second of those donations
        • 2007-10-28 - Michael Paoli e-mailed Andrew Fife regarding 501(c)(3) status (also checked earlier with Jim Stockford regarding possibly handling that via sfccp)
    • need to coordinate hardware migration strategy (Michael Paoli, Jim Stockford, et. al.)
      • most recent indications are build of new box will be started sometime on/after 2007-10-29
  • get more control into hands of webmaster(s), PHP assistant(s)/consultant(s)/fixer(s), etc., (Michael Paoli working to set these up) e.g.:
    • more automagic updates of [www.] from
    • various staging/test/PHP areas (mostly done weekend of 2007-11-03, there are now separate new, beta, and test areas)
    • better ways for webmasters to control when updates occur and have more free reign with website (at least for testing purposes, anyway)
  • continue to tweak and improve our dining experience and coordination (cat herding and menu improvements, avoiding musical chair syndrome, etc.)
  • survey the membership / meeting attendees?
  • continue to line up speaker(s)/presentation(s) more future meetings
  • In general, increasing moves to a more "production" infrastructure (reliable and redundant web, lists and e-mail) (probably don't need super-high availability, but being able to fail over or recover to alternate system in relatively quick order (minutes to hours, rather than days to weeks) would be a very good thing)
    • to provide virtual host - that should cover us pretty well in regards to redundancy/failovver
      • 2007-10-01 virtual host contact information passed along to Michael Paoli
      • 2007-10-21 Michael Paoli followed up with contact on initial questions (e.g. setup, options, etc.) & again on 2007-11-06
      • 2007-11-06 heard back from contact
  • Migration off of - including salvaging all that's feasible and of significant interest to BALUG, and smooth migration
    • control of and (eventual) migration of DNS (
      • Michael Paoli: e-mailed domain registrant on 2007-09-08 & 2007-09-30
      • Michael Paoli: left phone message(s) and e-mailed again on 2007-10-10
      • Mae Ling Mak may have e-mailed and/or called domain registrant 2007-10-14
      • received an e-mail from domain registrant & replied on 2007-10-15
      • Michael Paoli: e-mailed domain registrant again on 2007-11-06
      • e-mail received 2007-11-06 from domain registrant
      • Michael Paoli e-mailed domain registrant again on 2007-11-08 (with a bit of luck, we may have the registrant control stuff all wrapped up within about 5 to 10 days or so)
      • need to follow-through as necessary to gain control of registrant and DNS delegation information … without being excessively pesky about it
    • lists and list archives (including passwords, names, preferences, etc.)
    • lots of wiki pages that were functional there
    • presenter information, presentation/slides and such, and links to such,
    • meeting writeups/minutes of past several years
    • past approximately 3 years of BALUG history
    • (most) all the HTML page stuff
    • information for speakers
    • speaker coordination resources
    • spiffier information on directions to the meeting location
    • other useful resources and pages of information
    • etc.
    • get regular off-site automated backups in place (covering absolutely everything BALUG has hosted on, if feasible - e.g. including stuff that only allows access to via MySQL client)
      • have some manual backups of some(/much/all?) of the content
    • new landing places for stuff moved/extracted off of
      • - where should that be? (at least thus far and temporarily, it's on the box … but it could be almost anywhere)
      • box (and the major migration/upgrade of that to a new box!)
        • BALUG has an IP ( for its use on that box
        • basic new web infrastructure exists
        • Mailman (list software) is installed on box, but isn't configured yet
        • BALUG needs to create its own e-mail infrastructure off of (not yet in place, other than the box has been reconfigured so it's not using for SF-LUG / default e-mail on the box). Note also that BALUG is also (at least thus far) using some of the e-mail infrastructure (most notably a bunch of forwarding aliases).
        • wiki - has a wiki configured for it (and BALUG is using some of that) … but don't yet have such configured separately for BALUG (under it's own IP address and DNS names and such) - so, the BALUG stuff that's there so far may not be at all in it's "permanent" location.
    • content extraction
      • Any PHP and MySQL volunteers? (As of 2007-09-24 we've started to get at least some volunteer(s) to step forward on that.) BALUG could use assistance/consulting advice with PHP and MySQL; that could aid transition from the old hosted site of and Maybe we can leverage some "talk" list(s) or similar resources for answer to specific questions? Nothing all that major to do, but those aren't at least presently expert fields of the current BALUG sysadmins, and they'll likely otherwise manage to muddle through them anyway. Mostly just need to dump/migrate some MySQL data - and preferably in most useful/portable format(s) feasible - e.g. we may want to reload all the Mailman related data into a different MySQL database, but for some of the other data, we may want to process and pull out relevant bits via perl or other means. There's also some (slightly) broken PHP stuff to fix (or diagnose and make a "fix" recommendation). Presumably (my best guess) the PHP stuff was all working with the same, or a slightly older version of PHP, and changes in PHP version and/or some minor goofs in some PostNuke PHP web data have gotten the "old" stuff to the point where it's effectively quite non-functional … but it's probably not all that horribly difficult to fix … at least enough to usefully extract information - which is key objective. Anyway, if some person(s) want to volunteer a bit of assistance/consulting on MySQL and/or PHP, that may be of significant benefit to BALUG.
      • List archives and subscribers, etc.
        • automate backups of this data, as complete as feasible
          • it's presently being done approximately monthly manually (last done 2007-10-21); covers a rather imperfect and limited view of archives (munged @ –> " at " and most headers stripped, and no backup of any attachments), and list subscriber e-mail addresses (but not names, passwords, or preferences)
        • optimal extraction/migration may require fair bit of use of MySQL
      • Older web content (most notably many wiki pages)
        • "just in case" backup of raw data - may have some(/much/all?) of that covered, but that's also a worst case extraction scenario (may not be feasible to extract and reconstruct from such outside of environment)
        • optimal extraction/migration probably requires some (more) PHP expertise and possibly also some (more) MySQL expertise
    • DNS phased migration off of
      • have created and (including slave(s))
      • start phased change of (get registrar control, add NS records for
      • add slaves for (have queued up good volunteer slave resources once we can allow them to do zone transfers)
      • continue to maintain zone in mode compatible with until fully migrated off of (work in progress - currently being done with (to be new) primary master on
    • e-mail (, etc.)
      • The e-mail addresses are mostly fairly managed at this point - have functional forwarding aliases in place, have the information on the expansion of the aliases also on the box. Main thing missing from is reasonable spam filtering - doesn't offer spam filtering for forwarding only e-mail addresses - they only offer it for e-mail addresses that are fully hosted on (e.g. the mail stays on and is accessed via a web interface … not very handy for forwarding aliases where one wants the mail to be sent to multiple recipients).

This list originally based upon some earlier partial lists / status reports, e.g.:
Any good words as to the gathering of data from the old balug website ? updated! :-) (& related information)

Steering Committee

2007-10-01T12:00:00-0700 Conference Call


  1. The Big Plan
    • BALUG in general
    • sponsorships/funding/budgets/policies, etc.
    • general direction, plans, and vision for BALUG?
  2. BALUG Web & Email Issues
    • - where, objectives, participants, etc.
    • longer term Internet plans (redundancy, fail-over, RSVP system, etc.)
    • Website
      1. Do we have access/own all of the resources that we need?
        • not yet:
          • need to get full control of DNS (Michael Paoli/Mae Ling Mak following up on this)
          • redundancy/failover? Once we're off of DreamHost we're down to exactly one system shared with SF-LUG - and that system will be going through major changes soon (i.e. downtime).
            • What are BALUG's requirements for hosting the site?
              1. System & Storage?
              2. Physical Access?
              3. Bandwidth?
      2. Can we move forward without the old broke mysql stuff?
        • yes and no:
          • yes - we've got - can put it anywhere we want and use it as long as we want
          • no:
            • unless we want a gaping hole in BALUG's history, archives, and web site, etc., we still have more work to do to extract 2003-09 - ~2007-03 content (meeting minutes/links/summary pages and contents from speakers, various other useful web & wiki pages)
            • we can't smoothly transition the lists without doing some well timed and coordinated mysql extracts and loads. Yes, we can get subscriber's e-mail addresses, and a slightly munged form of the list archives without the mysql pieces, but without the mysql pieces we'll lose all the other stuff (e.g. list subscribers names, preferences and passwords, non-munged archive contents, etc.)
      3. Anyone opposed to a hosted wysiwyg solution like
        • yeah, I'm not keen on the idea:
          • Haven't we already been sufficiently screwed by "managed hosting sites" where we don't have full control of the materials/tools/software/etc. and easy ability to quickly replicate the same functionality and content elsewhere?
          • "managed hosting" sites usually let us do what we want - but only so long as it's something the hosting provider will let us do - it can be very constraining and problematic. We really don't need more of those issues/limitations.
          • do we really want to be subject to terms that aren't under our control and can be changed at any time without notice, and be agreed to the terms in advance?
          • various folks might also object on various "political"/freedom grounds.
      4. How can we implement an RSVP system for events?
        • for now: simple e-mail alias (That's what BALUG had historically)
        • future: snazzier web form, with reminder option(s), etc.
          • Should reminders be optional?
        • we probably want to avoid some 3rd party system that folks may not particularly trust and/or that may have terms some or many may find objectionable (e.g. many folks don't want their e-mail addresses made available to yet another 3rd party site that may end up leading to spam or unwanted promotional e-mails, etc.)
        • we probably need to consistently "push" folks towards RSVP to get RSVP responses that would be reasonabe indicators of probable attendance. E.g. if the event is promoted and publicized in inconsistent ways (not necessarily a bad thing itself), but when it's promoted, if there's nothing that implies folks need to RSVP, or they need to refer to our web site (where it would tell them they need to RSVP), then they typically wouldn't RSVP - and as publicity coverage (and response) may vary, we may be left with litle clue as to how many folks to actually expect.
    • Which lists/locations? What is the timing? Who posts?
      1. Internal BALUG mailing lists
      2. External UG mailing lists
      3. RSS from the website?
        • feasibility & implementation timing?
        • perhaps in the future, but not yet
      4. iCal and/or similar notification/calendaring systems?
      5. Flyers
      6. Member blogs
      7. Speaker blogs
      8. Event listing websites
      9. Social Networking: Facebook, MySpace, others?
  3. Speaker Coordination
    • What is our goal… driving meeting attendance or supporting local causes? (JS: entertain and/or enlighten members attending the meeting, not either driving meeting attendance, which should result from entertain/enlighten, nor support any particular cause other than general free and open source -ness.)
    • How to ensure that we don't double book speaking slots?
      • Update BALUG Speaker Coordination (note that that page may eventually move - but for the time being, that's where it is) - that's what it's there for. If one doesn't put information there that a speaker is booked/confirmed (or even tentative) for a date, then folks will presume the date is open. Folks aren't going to remember that e-mail from N days/weeks/months ago - especially if they weren't on at the time (and having a bunch 'o individuals trying independently to track the status would be rather redundant with what the wiki page is intended to do; also if folks separately maintain their own copies of such status, when they have conflicting information, how would one determine which information is correct? … with the wiki page it's out there for all to see (and even the revision history of who made what changes and when)).
      • also use for general speaker coordination - e.g. so the rest of the speaker coordinators are at least aware of some of the key bits of information - like how to get in touch with the speaker and any issues/communications of note. Don't make yourself the single point of failure. Also make sure the speaker is aware of for contacting us. That doesn't mean every bit of communication needs to go out to, but if aliens abducted you for a couple weeks, enough communications should have already gone out to that we'd be able to reasonably pick up the pieces.
    • Best Practices Guide for Speakers
      • did a quite good page of that before; it's still to be extracted from the old BALUG wiki stuff (and no, I don't feel like writing up all that work again, but if someone else wants to, feel free; we can always reintegrate useful bits from the older materials into a newer writeup once we've retrieved the older materials)
  4. Event Logistics
    • Update from Mae Ling on the Four Seas
      1. Menu Changes
        • Number of dishes won't change
        • Variety will change & rotate monthly between 4 entrees from the beef, pork, chicken & veggie menu items (yum!)
        • Menu will rotate monthly between noodles & rice, both of which will be veggie (yum!)
      2. 50+ people, we can eat upstairs (how to forecast this?)
      3. No more Musical Chairs (yippie!)
        • Portions of food will be determined by the number of blue tickets instead of by number of people sitting at the table
      4. Feb. 2008 - 2008-02-19 - any conflicts between date, venue, and Chinese New Year? No, we're all clear on that date (and in 2009).
    • Name tags? - probably, but need to be sure we do it in a time efficient manner (e.g. don't slow up dinner to do name tags!)
    • Address bottlenecks:
      1. Sitting down for dinner promptly - at 7:00 P.M.!
      2. Selling dinner tickets - in bar, upon arrival - or certainly before leaving bar area
      3. Late comers
      4. Musical Chairs & non-eaters
      5. Dinner to speaker transition - works better if we dine upstairs; short of that, timely start on dinner helps a lot
      6. Door Prizes - speed it up - draw at most for 3 items
    • How can we improve the AV equipment?
      1. Portable Projector (Can borrow from Untangle, Speaker is bringing his own for October)
      2. Portable Screen (About $300) (that might be okay for 25 folks, but when we have 50+ folks would a portable screen even help us at all?)
    • Time for community announcements, how to keep them concise & on topic? - _The Gong Show_ tactics - 60 second maximum per person - go over time or off topic and that's the end of that announcement
    • Publicizing the next event: Event Communications
  5. Finances
    • setting up a bank account
      • via USENIX/BayLISA?
      • via ???
      • via Jim Stockford?
    • budget for flyers, website & anything else?
  6. Mailing Lists
    • Keeping Mailing Lists Useful
      • this has mostly been a non-issue so far:
        • the Mailman list software is pretty good at detecting and snagging spam
        • "announce" is moderated
        • "talk" and "admin" have fairly open policies; listadmin(s) can warn/squash the problematic if/when that becomes necessary
balug/balug_todo_list.1267082737.txt.bz2 · Last modified: 2010-02-25T07:25:37+0000 by michael_paoli