[volunteers] Visibility & Volunteering

Rick Moen rick at linuxmafia.com
Thu Nov 7 11:48:20 PST 2013


Quoting Tim Utschig (tim at tetro.net):

> Some more thoughts on this:
> 
>   http://tetro.net/svlug/social-practices.html
> 
> Your thoughts?

Oh, I think you're spot-on.

Although I personally have no use for such things (the various social
networks), there is obvious value in a presence for outreach purposes, 
and SVLUG would be lucky and grateful to have anyone volunteer to 
shepherd that.

Just for the benefit of others reading this thread, when you speak of
$19+ for a Meetup Group, you are saying per month.  Reference:
http://help.meetup.com/customer/portal/articles/465027-organizer-dues-price-plans

If you're willing to foot that bill, fantastic.  We'd be idiots to say
much else besides 'Thank you.'

About the 'how to maintain access to various accounts', one thing we do
is maintain text records in shell-accessible files in the www.svlug.org
virtual host at Linode.  Specifically, there are a half-dozenish ASCII
files in a shared directory to store any information deemed sensitive
enough to not merely put them on one of our Web pages.  The very most
sensitive information goes into text files in /root on that machine.
(My recollection is that the only data there is the login credentials to
administer our Internet domains at registrar Joker.com.)

If you want to have 'role' @svlug.org mail aliases for this stuff, we
can certainly do that easily.  As you say, mailing lists can be created
to back-end such information, if that makes sense.  There are details we
could discuss about how to make that practical and avert the spam
problem, but I don't want to overburden this thread.


> P.S.  I'd also like to put forth an offer to help with speaker
> coordination, web team duties, or whatever needs doing.

Sure, you bet.  As we discussed, SVLUG's Internet presence remains split
(for the time being) between two hosts:

www.svlug.org:   o Main Web pages (98% static; headers, footers, and a few 
                   gadgets lovingly recoded into PHP5 by Lisa Corsetti),
                   (lighttpd w/PHP reached via FastCGI)
                 o DNS authoritative service (nsd)
                 o version control (svn)
                 o crond, sshd, ntpd
                 o For obsolete historical reasons (virthost used to have
                   way too little RAM and disk), this host has NO mail
                   service + no Mailman
lists.svlug.org: o Mailman's CGI-generated Web pages (Apache2 w/Mailman's CGIs)
                 o Mailing lists (Mailman)
                 o SMTP (exim4)
                 o spamd (daemonised spamassassin) + sa-exim (shimmed into 
                   the MTA to measure spamicity early before accepting)
                 o crond, sshd, ntpd

I believe you've had shell on one or both before.

Shell on www.svlug.org is needed to maintain our Web pages.  Shell on
lists.svlug.org is almost never needed at all, but in theory might be
needed for the more arcane bits of Mailman surgery that are almost never
needed.  Also, I ended up ssh'ing into there two nights ago because the 
sa-exim + spamd setup was 550-refusing Mark Weisler's post to
svlug-announce on grounds that his sending address could not be
validated as a reachable SMTP address.  To fix this annoyance (without
needing to look into why our host's STMP 'callback' checks failed Mark's 
address), I added Mark's sending IP address to a whitelist.

As we discussed, speaker coordination is the most urgent problem in my
opinion.  You can do that by just writing to possible speakers about
upcoming SVLUG dates (but see below) and getting them to commit to one
and giving us a talk title, brief talk description, and bio paragraph.


Ah, good news:  Mark said on Sept. 25th that we have a December
speaker/topic lined up Chander Kant and Paddy Paddy Sreenivasan from
Zmanda about the Amanda backup utility and how their company Zmanda 
uses it.  http://lists.svlug.org/archives/volunteers/2013q3/004393.html

And I'd have known that if I had bothered to look on
http://www.svlug.org/ instead of being all pessimistic.  Mark has been
on top of things.  (Thank you, Mark!)

I've never done speaker coordination, but gather that there's an art to
the timing of when and how many times to contact prospective speakers
and confirmed speakers.  What I mean is:

1.  People rarely agree to speak on short notice.  (Tolerance 
    differs, but when you get below two weeks resistance goes way
    up, usually.)

2.  Many people give odd/vague responses if you ask about them committing
    to a date too far out.  I guess this reflects most people not 
    effectively managing their calendars more than about two months
    away, or at least not being used to it.

3.  People are more willing to theoretically agree to an unspecified
    future date than to a specific one.  (However, the theoretical
    agreement is nonetheless useful as a point of discussion for 
    a specific date.)

4.  It's a really good idea to reconfirm with scheduled speakers 
    about, say, a week before the talk -- both because they might
    have forgotten and because they might have a new conflict and 
    have failed to tell us.   A reminder e-mail to the spaker is 
    both a tactful reminder and a means of detecting a problem 
    situation in time to possibly slot in a substitute.




FWIW, I am volunteering to give the next SVLUG talk.  Details in a
moment.

I just spotted something:  The January 2014 SVLUG date (1st Wednesday)
is going to be January 1st.  I think it'll be prudent to cancel that
meeting.

Subsequent meeting date will be Wednesday, Feb. 5, 2014.  I am proposing
to do one on 'How to get screamingly fast performance with Linux'.  I
have a few of the details worked out, and will certainly have a full
lecture by the beginning of February.

As I mentioned to Tim last night, the idea for that talk came to me
through an exercise in contrarian thinking.  I'd been planning the
safest, most conservative design for filesystem layout, mount options,
and so on for a Linux server.  Suddenly, I thought:  What about the
opposite problem?  How would I construct and configure a Linux host for
absolutely maximum performance with no regard to data protection --
like, assuming everything's backed up and what you want is
balls-to-the-wall maximum performance.  Turns out, it's rather fun to
research.





More information about the volunteers mailing list