Mailing lists using usenet newsgroup

[jim]

     (top posting per Rick's basic message) My
underlying motive is to allow others to participate/
collaborate. About that, one of my favorite stories is

     "The suits in some company discovered some
imperative reason to develop a prototype for a
new system related to their mission. Maybe this
was a hope to capture a new, rich client.... But
they had to present the working prototype in
five weeks.
     "The suits went to the engineers with this idea.
Engineers generally know their places and know
they have to say 'yes' to the suits as a general
posture. The engineers said 'yes'.
      "A week later the suits went to the engineers
to ask about progress. The engineers explained
that they were still planning. The suits went
back upstairs.
     "After two weeks, the suits returned to the
engineers, who explained that they were still in
the planning phase. The suits went back upstairs,
but their lunches were ruined.
     "After three weeks, the suits returned and the
engineers let them know they were still in the
planning phase. The suits went back upstairs
fully anxious.
     "They made it. At the end of the five week
period the engineering team had developed a
satisfactory working prototype."

     I'm not really doing this for me; rather I hope
that a few members of the group will join in the
talking and blathering and we will all learn, and
hopefully more and more quickly than if we
work in solitude. Of course, it'll be important to
move out of the planning phase.
     Rick, your comments are a terrific help in
this planning phase. I'll look things up and hope
a few others in SF-LUG do, too.



On 01/07/2015 09:49 AM, Rick Moen wrote:
> On Wed, Jan 7, 2015 at 8:44 AM, jim <jim at well.com> wrote:
>
>>      I'm not trying to defend or excuse myself; rather I
>> hope my confession helps someone reflect and possibly
>> improve.
> I didn't fault you for anything, Jim.  I just wanted to remind
> everyone about fundamentals.  Heavens knows I've cut corners myself
> and made errors, but I've also tried to never make the same exact
> error twice. I even once lost a couple of weeks of updates to my Web
> server, received mailing list traffic,received e-mail, sent e-mail,
> and updates to my and others' files in home directories, because my
> very casual backup scheme hadn't been run in a while.  But at least I
> did have backups, however intermittent.
>
> Another one of my rules of thumb is that the half-assed, 80% solution
> you actually do beats the perfect, polished solution you never quite
> got around to, every time.  For example, my backups rely mostly on
> periodic backups of critical file trees to an external, detachable
> hard drive.  That's pretty half-assed -- but it's good enough, and I
> actually do it.
>
> I put heavy reliance[1], for some years, on all of my server's
> filesystems that matter on a RAID1 mirrored pair of hard drives.  When
> one of the two drives failed, and I lacked time and energy to fix that
> problem right away, I rushed out to do the next best thing:  I bought
> a detachable external hard drive, and did much more frequent backups
> than before.  With my laptop, I became increasingly anxious about the
> risk of its SSD failing, with my having in effect _no_ backups of its
> files, so I finally found an external drive and now both do regular
> backups to it and periodically test the integrity of same.
>
>> I believe that you several times wrote about backing
>> up the MailMan data and meta-data, yet I was possibly
>> * too unfamiliar with some aspects of Unix and *nix systems
>> * too distracted or stressed or lazy to explore
>> * needed more involvement with others sharing the same
>> sense of immediacy
> Well, regard this as an opportunity.
>
> Here's something to ponder:
> https://web.archive.org/web/20130331052337/http://linuxmafia.com/faq/Admin/linuxmafia.com-backup.html
>
> That's a scheme that I've been using, and refining, for years.
> Recently, I was bowled over to discover, nonetheless, an error in it.
>   The steps I had been taking to back up /var/spool/mail, which
> directory houses the MTA's spool of received mail for various users,
> had been ineffective.  Why?  Because Debian in its dubious wisdom had
> at some point decided that the MTA mail spool should be in /var/mail,
> and left /var/spool/mail as a symlink pointing there.  My rsync
> command to back up /var/spool/mail was copying null contents, and I
> hadn't noticed.  Fortunately, I corrected this error and added
> /var/mail/* to my backup set.
>
> The major value of that Web page for me is its documentation of which
> subtrees on my server system it makes sense to back up.  This was the
> fruit of careful study -- and yet, even with that caution, it
> accidentally omitted one significant subtree because Debian moved
> those files and, although I knew they did that, I hadn't made the
> connection about my backup scheme needing revision.
>
>> Assuming so, seems to me that sf-lug and dv-lug might
>> benefit with a shared backup regimen.
> Might I suggest process thinking?  Set up Mailman, play with it, get
> to know it well.  Get to know how to backup and restore.
>
> You can do that starting right now.
>
> Talking about 'ideas' is just blather.  You want to get something
> done, good:  Go get your hands dirty.
>
>> My idea is to find out what MailMan facilities allow full
>> backup as well as incremental backup:
> My suggestion:  Stop talking about 'ideas' and how to do things with
> all the bells and whistles, e.g., full as well as incremental.  (At
> your leisure, by the way, look up differential backups and learn why
> they make a great deal more sense than incrementals.)  Get your hands
> dirty, start simple, go for the low-hanging fruit.  You don't need to
> barrage people with questions or bounce 'ideas' off them to get this
> process underway.  What you need to do is work with technology and
> apply process thinking to it.
>
>> * somebody (hopefully not me, but I'm willing) catches the
>>     appropriate MailMan data to their laptop system, verifies
>>     the data restore, then makes sure the data is on some
>>     redundant storage device (my vote is USB stick or SSD
>>     or some such).
> USB stick?  Really?  Honestly?
>
> Damn, Jim.
>
> Tell you what:  I'm not going to keep acting like some sort of guru
> for you and tell you why that's not a very bright idea.  You need to
> stop the armchair theorising, do some work with Linux, and learn from
> it.
>
> Stop telling everyone what you think someone-nobody-in-particular
> should aim to achieve as an end-goal (classic non-process thinking).
> Instead, go do things.  Because this other stuff is not the way to get
> anything done.
>