[Discuss] Reminder: BLU Desktop GNU/Linux SIG Meeting - Learning to Change the World - Weds, Nov 5, 2014

2014-11-03 Thread Will Rico
When: Wednesday, November 5, 6:30 - 8:30PM

Location: Akamai, 8 Cambridge Center, Cambridge, MA

Directions
  http://www.akamai.com/html/about/driving_directions.html 

  Also easily accessibly by T.

Cost: Free

Notes

  1) Please note the location is different from BLU's
 standard MIT meeting location.

  2) Akamai has generously agreed to provide space
 and 'free as in food' for this meeting.
 Thank you to our sponsor!
 http://www.akamai.com/

Summary

  Join us as Walter Bender
  presents "Learning to Change
  the World: How the Technology
  and Culture of Free Software
  Can Fuel a Learning Revolution
  One Teacher and One Child at a
  Time."
 
  Walter Bender is founder and
  executive director of Sugar
  Labs. Sugar Labs is a member
  project of the non-profit
  foundation Software Freedom
  Conservancy.  Sugar Labs
  develops educational software
  used by more than
  three-million children in more
  than forty countries.

  In 2006, Bender co-founded
  the One Laptop per Child, a
  non-profit association with
  Nicholas Negroponte and 
  Seymour Papert.  As director
  of the MIT Media Laboratory,
  Bender led a team of
  researchers in fields as
  varied as tangible media to
  affective computing to
  lifelong kindergarten.  In  
  1992, Bender founded the MIT 
  News in the Future consortium,
  which launched the era of
  digital news.

More Events & Announcements

  Jeff Schiller on Security
  Weds, Nov 19 at MIT
  http://blu.org/cgi-bin/calendar/2014-nov

  Installfest LIV (Hands-on)
  Sat, Dec 6 at MIT
  http://blu.org/cgi-bin/calendar/2014-ifest54

  Meet the Creative Commons with Matt Lee
  Weds, Jan 7 at Akamai
  http://www.meetup.com/desktop-linux-users-group/events/217495612/


   

___
Announce mailing list
annou...@blu.org
http://lists.blu.org/mailman/listinfo/announce
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss


Re: [Discuss] Revisiting VMWare ESX backup options

2014-11-03 Thread Richard Pieri

On 11/3/2014 1:53 PM, Rich Braun wrote:

Additional layers of security, whether "necessary" or not, are worthy of
discussion.  Encryption is pretty darned easy to use, doesn't add burdensome
complexity (depending on the tool you select),


Backing up encrypted desktops and notebooks is a pain in the ass. Bare 
metal restores are impossible or damned near.



and is very often necessary for cloud deployment.


My opinion of this should be well known around these parts by now. :)


(I happen to work in an enterprise-software team deploying
to AWS, so there's no choice: we encrypt. Everything.)


By choosing to use AWS you have chosen to accept the risks associated 
with handing over your stuff to a third party. By relinquishing physical 
control you have made it easier for a bad actor to gain access. All the 
encryption in the world won't stop an attacker who gains access to your 
AWS control panel.



For home/small-business
users, the odds of theft or human-error are considerably higher than in an
enterprise situation, depending on your location and other variables.


That's no excuse for carelessness. See previous discussion about dog 
cages. If your data is that important to you then you should put 
commensurate effort into physically securing it. If you refuse to do so, 
well, no sympathy from me.


--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss


Re: [Discuss] Revisiting VMWare ESX backup options

2014-11-03 Thread Rich Braun
Richard Pieri 
> Physical security comes first. Encryption is no substitute for physical
> access controls.

Agreed. They are two separate layers of security.  You can do one, or the
other, or both, or neither.  You decide.

> If you refuse to maintain physical control over your
> data and equipment then you deserve what happens to it. I have no
> sympathy when it does. I laugh and I point and I say "I told you so".

Respectfully, we do not agree on this point. Loss is no laughing matter, no
matter what mistakes were made by he/she who suffered the loss. The point of
this discussion is to encourage readers to think about appropriate steps to
protect against future loss. No security is 100% effective, there will be
future losses and it's impossible to say how or when.

Additional layers of security, whether "necessary" or not, are worthy of
discussion.  Encryption is pretty darned easy to use, doesn't add burdensome
complexity (depending on the tool you select), and is very often necessary for
cloud deployment. (I happen to work in an enterprise-software team deploying
to AWS, so there's no choice: we encrypt. Everything.) For home/small-business
users, the odds of theft or human-error are considerably higher than in an
enterprise situation, depending on your location and other variables.

-rich


___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss


Re: [Discuss] Nagios config

2014-11-03 Thread Matt Shields
If you're going to use Nagios, use Icinga instead.  Same modules, same
configs, better interface.  One example is say you are trying to
acknowledge a number of services that are down.  In Nagios you need to
acknowledge them one by one.  In Icinga, you can select them all, then do a
mass acknowledgement of all of them.

Matt

On Mon, Nov 3, 2014 at 11:59 AM, John Malloy  wrote:

> We are setting up Nagios for the first time in our shop.
>
> Does anyone have suggestions on build,  initial configs and autodiscovery,
> etc?
>
> Thanks!
>
>
> John Malloy
> jomal...@gmail.com
> ___
> Discuss mailing list
> Discuss@blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss


[Discuss] Nagios config

2014-11-03 Thread John Malloy
We are setting up Nagios for the first time in our shop.

Does anyone have suggestions on build,  initial configs and autodiscovery,
etc?

Thanks!


John Malloy
jomal...@gmail.com
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss