March 2009 - BALUG-Admin - lists.balug.org

Re: [BALUG-Admin] I'll also update http://lists.balug.org/listinfo.cgi/balug-announce-balug.org
by Michael Paoli 14 Apr '09

14 Apr '09

Quoting "Rick Moen" <rick(a)linuxmafia.com>: > Quoting Michael Paoli (Michael.Paoli(a)cal.berkeley.edu) > >> I'll also update >> http://lists.balug.org/listinfo.cgi/balug-announce-balug.org >> to make [1] a bit more clear (it's already quite clear on >> http://lists.balug.org/listinfo.cgi/balug-talk-balug.org >> and >> http://lists.balug.org/listinfo.cgi/balug-admin-balug.org >> ). > > Intending no criticism, here, Michael, but I'll be curious to see what > you'll be making a bit more clear. It was perhaps subtle enough one might not even notice. Anyway, on: http://lists.balug.org/listinfo.cgi/balug-announce-balug.org I added (note also placement, emphapsis, and link used in the above) text: " (If you're subscribed to other BALUG list(s), but not this one we may subscribe you! See: BALUG-announce-do-not-auto-add.html if you want to be exempted from that and/or for additional related information.) " ... mostly just to round out covering the bases and for preventive maintenance purposes - e.g. scenario where someone's subscribed to "announce" and also subscribed to other BALUG list(s) - so they're not, perhaps repeatedly, surprised finding themselves resubscribed to "announce". It's covered rather/quite well elsewhere, ... but folks tend to forget. Not much of an issue yet, as the auto-add thing isn't yet fully automated (once I have the data - which I gather once in a while anyway for backup purposes (typically about monthly or so) - run a script, paste two places on the "mass subscribe" form, and the relevant folk(s) are added to "announce"). > One reason not to try to make Mailman listinfo pages "a bit more clear" > about unsubscribing is, in my experience, if you overexplain, people > tend to think you're not serious, which then encourages them to say > things like "unsubscribe me; I tried and it doesn't work." Yes, point well taken (and you've made the point well before, too :-)). I tried to keep the additions/changes relatively minimalist, appropriately placed, easily referencing (but not directly including) details as appropriate (done via a link), and with the appropriate emphasis on key point(s).

4 12

dreamhost list issues?
by Michael Paoli 01 Apr '09

01 Apr '09

Hmmm, just noticed, getting some errors on the dreamhost hosted list archives, e.g. this works: http://lists.balug.org/pipermail/balug-announce-balug.org/2009-March/date.h… but following liks from there, e.g.: http://lists.balug.org/pipermail/balug-announce-balug.org/2009-March/000125… doesn't work Seems to mostly (or entirely) be just some of the newer archived stuff (or stuff that *should* be archived). I'll check further and see what I find.

2 2

Lists: stats, etc.
by Michael Paoli 27 Mar '09

27 Mar '09

YYYY-MM-DD announce talk admin 2009-03-27 677 287 29 2009-01-10 662 290 30 2008-08-17 635 290 29 2008-03-03 571 247 28 2008-02-07 563 268 28 2008-01-02 337 260 28 2007-12-28 336 261 28 2007-10-21 304 251 27 2007-09-03 264 258 27 2007-07-24 287 256 27 2007-06-17 280 249 27 references: http://lists.balug.org/pipermail/balug-admin-balug.org/2009-January/000631.…

1 0

Re: [BALUG-Admin] [BALUG-Announce] TOMORROW!: BALUG: Tu 2009-03-17 Jordan Gray (STARPAUSE) talk/demo on DJing and Music Composition on Linux
by Andrew Fife 16 Mar '09

16 Mar '09

Hi rickd: [removing rsvp(a)balug.org<mailto:rsvp@balug.org> and including balug-admin(a)lists.balug.org<mailto:balug-admin@lists.balug.org>] Sorry for the difficulty that you are having unsubscribing. You should be able to unscubscribe from the following page: http://lists.balug.org/listinfo.cgi/balug-announce-balug.org You will also need to respond to the auto-confirmation email that is sent to all unsubscribe events in order to be removed from the list. I hope this is helpful. -Andrew -- Andrew Fife Untangle 650.425.3327 desk 415.806.6028 cell From: Rick DeGaetano [mailto:rickdegaetano@yahoo.com] Sent: Monday, March 16, 2009 1:48 PM To: rsvp(a)balug.org Subject: Re: [BALUG-Announce] TOMORROW!: BALUG: Tu 2009-03-17 Jordan Gray (STARPAUSE) talk/demo on DJing and Music Composition on Linux I have tried to unsubscribe to this list, it doesn't work, how can I get off of this list? Thanks, rickd --- On Mon, 3/16/09, Michael Paoli <Michael.Paoli(a)cal.berkeley.edu> wrote: From: Michael Paoli <Michael.Paoli(a)cal.berkeley.edu> Subject: [BALUG-Announce] TOMORROW!: BALUG: Tu 2009-03-17 Jordan Gray (STARPAUSE) talk/demo on DJing and Music Composition on Linux To: balug-announce(a)lists.balug.org Date: Monday, March 16, 2009, 12:53 PM Reminder: TOMORROW: BALUG: Tu 2009-03-17 Jordan Gray (STARPAUSE) talk/demo on DJing and Music Composition on Linux Bay Area Linux User Group (BALUG) Tuesday 6:30 P.M. 2009-03-17 Tu 2009-03-17 Jordan Gray (STARPAUSE) talk/demo on DJing and Music Composition on Linux Have you ever wanted to learn beat-mixing or electronic music composition? Want to get started with software that's completely free and community-based? Join us for an evening with STARPAUSE (a.k.a. Jordan Gray), chiptune producer and founder of the Mp3Death[1] (Creative Commons) netaudio label. Jordan will cover the basics of DJing and introduce you to the free open-source MIXXX[2] digital DJ software. Then we'll move on to tracker-based music composition using LittleGPTracker[3], which Jordan will demonstrate both on laptop and the Game Park handheld. LittleGPTracker is free and designed especially for 8-bit (GameBoy-style) music. Both software run on the free Linux operating system (Mac and Windows also available). 1. http://mp3death.us/ 2. http://www.mixxx.org/ 3. http://littlegptracker.com/ So, if you'd like to join us please RSVP: rsvp(a)balug.org **Why RSVP??** Well, don't worry we won't turn you away, but the RSVPs really help the Four Seas Restaurant plan the meal and they ensure that we're able to eat upstairs in the private banquet room. Meeting Details... 6:30pm Tuesday, March 17th, 2009 2009-03-17 Four Seas Restaurant 731 Grant Ave. San Francisco, CA 94108 Easy $5 PARKING: Portsmouth Square Garage at 733 Kearny Cost: The meetings are always free, but dinner is $13 http://www.balug.org/ _______________________________________________ BALUG-Announce mailing list BALUG-Announce(a)lists.balug.org http://lists.balug.org/listinfo.cgi/balug-announce-balug.org

1 0

(forw) Re: [sf-lug] balug.org DNS (was: sf-lug.com web site accessibility)
by Rick Moen 01 Mar '09

01 Mar '09

----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Sat, 28 Feb 2009 16:56:46 -0800 From: Rick Moen <rick(a)linuxmafia.com> To: sf-lug(a)linuxmafia.com Subject: Re: [sf-lug] balug.org DNS (was: sf-lug.com web site accessibility) Quoting Michael Paoli (Michael.Paoli(a)cal.berkeley.edu) > No changes regarding balug.org DNS that I'm aware of ... at least that > are or would be problematic. As an additional exercise, I'll now show you how I might check out whether balug.org DNS is OK. This is something _anyone_ can do, even MS-Windows sufferers. (There's a free-of-charge download of "whois" and "dig" programs in MS-Windows executable format on the Web.) In my former e-mail, I was launching shell commands inside of vi, while composing my mailing list reply in that editor -- indicating so doing by typing ":r! " at the beginning of a line to show a vi shell escape. In the following, for clarity's sake, I'll just show "$" to indicate a bash prompt, OK? First, we want to identify balug.org's _authoritative_ nameservers. Anyone can set up a DNS nameserver that claims to be publishing reliable balug.org DNS information, but the only ones people will _consult_ are the ones the parent zone -- that would be .org in the case of balug.org -- identifies as having authority over balug.org. There are two ways to do this. One is to ask the shared "WHOIS" registries that all of the domain registrars communicate with and share. One can do that with the "whois" command, looking specifically for the lines starting with "Name Server": $ whois balug.org | grep "Name Server" Name Server:NS1.DREAMHOST.COM Name Server:NS2.DREAMHOST.COM Name Server:NS3.DREAMHOST.COM Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: The other way is to ask the nameservers for "org." directly -- which makes this as two-step process, because you first have to find one of the six nameservers that serve up "org."'s information, and then ask one of them "What are the nameservers for balug.org?" The best tool, as for just about any other DNS query, is "dig": $ dig -t ns org. +short #What are org.'s nameservers? a0.org.afilias-nst.info. a2.org.afilias-nst.info. b0.org.afilias-nst.org. b2.org.afilias-nst.org. c0.org.afilias-nst.info. d0.org.afilias-nst.org. Now that you have the list of org nameservers, you can ask _them_ about balug.org's nameservers. I had to do a little fiddling, because it turns out that the people who now operate org aren't returning exactly correct results any more. (They should be giving data in the Answer Section, not just in the Authority Section that is omitted if you query using the "+short" flag.) $ dig -t ns balug.org @a0.org.afilias-nst.info. [...] ;; AUTHORITY SECTION: balug.org. 86400 IN NS ns3.dreamhost.com. balug.org. 86400 IN NS ns2.dreamhost.com. balug.org. 86400 IN NS ns1.dreamhost.com. Please note: The _order_ in which authoritative nameservers (or, for that matter, "NS" lines in zonefiles) are listed is _not_ significant. You have absolutely no idea which server will get used/consulted during normal DNS operations. dig's "@", by contrast, allows you to send a query directly to a specific nameserver, but DNS generally goes first to wherever that machine's DNS gets shoveled off to, eventually getting to data originated some time back by an unpredictably selected authoritative server and then cached for some period of time (with the result that you can't predict where it came from, and it might be obsolete). You might be thinking, "Hey, wait, what about the fact that one of the authoritative servers for the zone is the master, and all others are slaves?" Master/slave relationship for zonefiles has nothing to do with _serving_ of DNS. It solely concerns which of the authoritative servers publishes the master copy to the others -- and actually isn't essential to DNS at all, as there are other ways of propagating zone information (e.g., having several machines in dispersed locations all drawing data from a single database, as back-end data). Anyway, now that we know what three machines have authority for balug.org we ask them for the SOA record, which includes the zonefile S/N: $ dig -t soa balug.org @ns1.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 $ dig -t soa balug.org @ns2.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 $ dig -t soa balug.org @ns3.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 All of them report zonefile serial number "2008070600", which by convention means that it was last updated on 2008 07 06 (July 6, 2008) and was update #00 on that day. The fact that the three nameservers all report the _same_ S/N is encouraging, as it makes it very likely that they are in proper communication. Incidentally, one of the other SOA subfields, "ns1.dreamhost.com", is supposed to be where you declare the location of the master zonefile copy. However, the field value is strictly informational, and often (for many zones) lacks correct and useful data. (As noted above, the very notion that there's necessarily a master server for each zone doesn't necessarily apply.) Last, there's some merit to actually asking each of the nameservers about some record that's genuinely of interest, such as "www.balug.org" or "lists.balug.org": $ dig www.balug.org @ns1.dreamhost.com +short 208.113.160.236 $ dig www.balug.org @ns2.dreamhost.com +short ;; Truncated, retrying in TCP mode. 208.113.160.236 $ dig www.balug.org @ns3.dreamhost.com +short 208.113.160.236 Notice that Dreamhost is being a bit of a screwup, concerning "ns2.dreamhost.com": It's not giving useful, complete responses to UDP-based queries -- e.g., fragmenting them across multiple packets, which UDP doesn't support -- so, dig went back and tried again using a TCP-type query, which worked. Trying again a moment later worked without switching to TCP, so it was probably a temporary glitch. However, this underscores why it's important that you _not_ firewall off 53/tcp, when you're operating a nameserver. In an ideal world, I'd be in a position to know whether "208.113.160.236" is really the correct IP for www.balug.org, which I'm not, but someone actually running the domain (and especially its DNS) no doubt would. One last point about the SOA record: "hostmaster.dreamhost.com." is supposed to indicate the e-mail address of the administrative person responsible for the contents of the master zonefile, expressed with the "@" turned into a period on account of an antique software limitation that was in place when the RFC was written. So, the e-mail address is "hostmaster(a)dreamhost.com". It may or may not be in BALUG's interest for (theoretical) queries about the zone's contents to go to Dreamhost's DNS administrator. Does BALUG edit its own DNS? If it does, it might wish to put someone else's e-mail address there. (Note: However, hardly anyone ever uses that data, which is likewise an informational record only, and often doesn't have a useful e-mail address at all. Most often, people will contact the Administrative, Technical, or Registrant contacts from the WHOIS record, or just go straight for the webmaster as indicated on the Web site (if accessible).) _______________________________________________ sf-lug mailing list sf-lug(a)linuxmafia.com http://linuxmafia.com/mailman/listinfo/sf-lug ----- End forwarded message -----

1 0