Re: OT (or is it): Fw: The untold doomsday scenario in the Gulf

2010-06-21 Thread Technomage

On 6/20/10 10:05 AM, j...@actionline.com wrote:

Fw: The untold DOOMSDAY Scenario emerging in the Gulf . . .]

   

snip

it sounds all too sensational to me. However the alluding to corporate 
conspiracies is
probably more true than not. However, unless there is real evidence to 
support

the other mess in here, I tend to find it, well unbelievable.

I am not even sure that the amount of back pressure from the oil field 
would be enough
to push out (let alone leak around) 18,000+ feet of tightly fitted pipe 
with a concrete filler.


also, I tend to take anything posted at rense.com with a grain of salt.
I will tend to believe (given past experience) that the main stream 
media never tells the whole

truth (if it bleeds, it leads).

As for Dr. James P. Wickstrom, well, he's a commentator with some 
extreme views (I may be conservative,
but even this guy makes me more than a little nervous). Unfortunately, I 
have not been able to find
any relevant information as to what school he attended or what his 
Doctorate was in.


some other interesting reading about Dr. James P. Wickstrom:

http://wiki.answers.com/Q/Who_is_Dr_James_P_Wickstrom
http://en.wikipedia.org/wiki/James_Wickstrom

Given this information and the google relevant searches, I cannot even 
take this guy seriously.
until he comes up with scientifically verifiable evidence to back his 
claims, I view him as

nothing more than a panic monger and doomsday cultist.

---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss


Re: CloudLinux

2010-06-21 Thread Dan Dubovik
I've been playing around with CloudLinux a bit and haven't had a chance to
properly reply to this thread until now.  That said, CloudLinux itself is
not a virtualization layer in the sense of Xen, VMWare or the like.  It
instead is a way to limit system resources based on the user (uid) instead
of by process.

While CloudLinux does include some security features (a grsecurity patch,
utilization of fcgid / suphp for running cgi processes as the VirtualHost
user, instead of as the apache user), it's primary benefit is in the
limitation of CPU, I/O, and process count per user.  In a hosting
environment, being able to prevent one user from completely tanking a server
(either intentionally, as a result of a Digg or Slashdot article, or some
attack aimed at the site), this is a huge benefit.

IMO the name itself (CloudLinux) is somewhat misleading, as it does not
employ any Cloud features (no real abstraction of services from the
hardware).

@R P Herrold
I agree that the basic support is useless.  I do not know the pricing of
licenses / support as of yet, however, I suspect that Basic plan is simply
there to make the others look more attractive for whatever the price is (see
ATT's .5GB data package vs 2GB data package for a similar concept).

In the OT part of this thread, I would also agree that many of the security
risks of Cloud computing are much arm waving, and can largely be resolved by
proper encryption of data, in addition to using the Cloud properly.  There
are parts of it that can be useful (non-critical data storage, inexpensive
off site backups, etc), and parts that you may not want to keep out there
(unencrypted user SSN's, CC#'s, etc), more as part of good practice than any
real security concerns.

@Lynn
I also agree that any way we can make the bad guys keep scratching their
heads, gives us time to implement better policies and procedures to further
complicate their lives.  However, while we should try to keep our methods of
thwarting them quiet, it could also be beneficial to inform others who have
noticed (and been open) about the same attacks know what you did to resolve
it, even if done so out of band via a simple phone call, etc.

-- Dan
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: google CL tools

2010-06-21 Thread AZ RUNE
I agree and aside from gaming, I have been moving to a private cloud for all
my data which I can access from my Google phone or 12-inch netbook. Its been
interesting seeing Android dev's looking at an app for this as well.

Brian

On Sun, Jun 20, 2010 at 9:12 AM, Stephen cryptwo...@gmail.com wrote:

 http://www.theregister.co.uk/2010/06/20/google_command_line_tool/

 I think this is a great thing...

 --
 A mouse trap, placed on top of your alarm clock, will prevent you from
 rolling over and going back to sleep after you hit the snooze button.

 Stephen

-- 
Brian Fields
arizona.r...@gmail.com
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: ipod Linux....

2010-06-21 Thread Lisa Kachold
On Thu, Jun 17, 2010 at 2:51 PM, Stephen cryptwo...@gmail.com wrote:

 this amused me a great deal.
 http://www.ipodlinux.org/


 --
 A mouse trap, placed on top of your alarm clock, will prevent you from
 rolling over and going back to sleep after you hit the snooze button.

 Stephen


KUTE!
-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: Crackabiltiy of OpenSSL, GPG, bcrypt and scrypt

2010-06-21 Thread Lisa Kachold
On Wed, Jun 9, 2010 at 7:36 AM, gk gm5...@gmail.com wrote:

 I hope I am making an apples to apples comparison.

 I'm not talking about Debian's mess up awhile back. Nor am I talking about
 something that was flying around Debian's mailing list for OpenSSL,
 FUSE/ENCFS and AES ciphers.


 I'm talking overall. Which is the most stable, has the highest probability
 of not be broken in our lifetimes (20 yrs). Mainly I'm trying to center in
 on file management, not email. GPG is good for email, but I find that using
 OpenSSL is actually easier because it is by default installed on *nix boxen,
 AND is VERY VERY easily installed on M$ products compared to the massive
 hoops that have to be done for GPG on the later that even a well versed
 Linux user would be pressed to install right.

 scrypt claims it is much more difficult in its derivations than bcrypt
 which is 448 bit Blowfish. Thereby saying it is harder to crack. However,
 I can not find anything on scrypt that says what type of encryption method
 it uses much less bit value.

 So if you had a face off between OpenSSL, GPG and scrypt for file
 encryption. Let me say bcrypt has some funky responses once in a while to
 extra large files, ie  4gb. Which to use?


 gk

 --
 Remember, it's not that we have something to hide; it's that we have
 nothing to show.

 --Keep tunneling.


I would have to take the openssl road here!

Of course, maintaining the most recent stable version and upgrading when
security issues are found are required of all code or systems tools
management.

We are not even going to begin to discuss that entropy remains broken.

-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

OT: HowTo Gpartd Windows Mirrored Drives to Expand Usable Space?

2010-06-21 Thread Lisa Kachold
Gee,

Anyone know an easy tool or procedure to make a standard Laptop C and D
drive no longer mirrored instead 2 usable drives?

I heard a rumor that you can boot into say Knoppix and use gpartd?

-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: Using rsync to create two versions of the same software.

2010-06-21 Thread Lisa Kachold
On Tue, Jun 15, 2010 at 11:51 AM, Bryan O'Neal 
bryan.on...@theonealandassociates.com wrote:

 I agree SVN for version control, but for available features I just have a
 config file. For java you use a JNDI lookup or parse the XML based config
 file directly or JDBc to your dab based config what ever floats your boat,
 but basically you just set a variable - free = no - and then check the state
 of said var when laying out the site.  Same way you did it in the desktop
 only now you set the session var after cheeking login credentials instead of
 when you compile and distribute the software.


 On Tue, Jun 15, 2010 at 11:08 AM, Eric Cope eric.c...@gmail.com wrote:

 I use SVN for that. Specifically, EXPORT. Then I use a script clean out
 directories, then pass my PHP through the PHP compiler as a last time double
 check things compile.

 Eric

 On Tue, Jun 15, 2010 at 10:44 AM, keith smith klsmith2...@yahoo.comwrote:


 Hi All,

 In the old days of writing desktop applications, when one wanted to make
 two versions of the same app - one free or demo and the other with all the
 features, all one had to do was add a switch to include (run) or exclude
 (not run) the code to create either version and compile.

 Now that we have interpreted web based applications written in PHP and
 the like, this option does not work so well.  I was thinking about this
 recently and wondering how to address such an issue with PHP.

 Yesterday while looking at rsync I happened upon a website and read I
 personally use it to synchronize Website trees from staging to production
 servers.

 Then it occurred to me that I can use rsync for building two different
 versions of a PHP application.

 I can add that switch to the code and test each version by setting the
 switch.  Then I can run rsync to copy each code set to its own directories.


 The other solution would be to use a compiler.

 I suspect I could use this to upload changes to a production server.
 Configuring it to only copy files that have changed.  Interesting idea.
 Only down side is any code not ready for production would be uploaded to the
 production server as well.

 
 Keith Smith


Usually production servers in a PCI compliant network will not allow
scripted scp or rsync - even with keys.
Apache WebDAV required for svn write, and svn 389 are also excluded
generally in such an environment.

Hand based rsync (or scheduled) authenticated ssh push from internal QA
servers - originated from trust to DMZ is generally allowed.

 I doubt that even expect will be allowed in most complaint networks to
automate password challenges.

Ideas?

-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: Crackabiltiy of OpenSSL, GPG, bcrypt and scrypt

2010-06-21 Thread Tim Bogart
John Viega is probably one of the leading authorities on the vulnerabilities 
regarding SSL.  I used to have his book (signed of course), but that's another 
story.  For those who may be interested, 

http://www.infibeam.com/Books/info/John-Viega/Network-Security-with-Open-SSL/059600270X.html

It's an O'Rielly.

t





From: Lisa Kachold lisakach...@obnosis.com
To: gm5...@gmail.com; Main PLUG discussion list 
plug-discuss@lists.plug.phoenix.az.us
Sent: Mon, June 21, 2010 7:23:49 PM
Subject: Re: Crackabiltiy of OpenSSL, GPG, bcrypt and scrypt




On Wed, Jun 9, 2010 at 7:36 AM, gk gm5...@gmail.com wrote:

I hope I am making an apples to apples comparison.

I'm not talking about Debian's mess up awhile back. Nor am I talking about 
something that was flying around Debian's mailing list for OpenSSL, 
FUSE/ENCFS and AES ciphers.


I'm talking overall. Which is the most stable, has the highest probability of 
not be broken in our lifetimes (20 yrs). Mainly I'm trying to center in on 
file management, not email. GPG is good for email, but I find that using 
OpenSSL is actually easier because it is by default installed on *nix boxen, 
AND is VERY VERY easily installed on M$ products compared to the massive 
hoops that have to be done for GPG on the later that even a well versed Linux 
user would be pressed to install right.

scrypt claims it is much more difficult in its derivations than bcrypt which 
is 448 bit Blowfish. Thereby saying it is harder to crack. However, I can 
not find anything on scrypt that says what type of encryption method it uses 
much less bit value.

So if you had a face off between OpenSSL, GPG and scrypt for file encryption. 
Let me say bcrypt has some funky responses once in a while to extra large 
files, ie  4gb. Which to use?


gk

-- 
Remember, it's not that we have something to hide; it's that we have nothing 
to show.

--Keep tunneling.

I would have to take the openssl road here!

Of course, maintaining the most recent stable version and upgrading when 
security issues are found are required of all code or systems tools management.

We are not even going to begin to discuss that entropy remains broken.  

-- 
Office: (480)307-8707
ATT: (503)754-4452 


  ---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: What syntax for global 'chown' fix?

2010-06-21 Thread Lisa Kachold
On Tue, Jun 8, 2010 at 12:53 PM, Dan Dubovik dand...@gmail.com wrote:

 For the record, I'm with Dale here.  Generally speaking, running a chown /
 chmod against an entire system is bad.  There are system files that have
 setuid / setgid set, and for good reason (/bin/su comes to mind).  There
 could be uses for specific directories however, and with that in mind:

 From the find man page:
-P Never follow symbolic links.  This is the default behaviour.
  When find examines or prints information a file, and the file  is a
 symbolic link, the information used shall be taken from the properties of
 the symbolic link itself.

 So to shorten Kaia's command, just add -P to it, and it will ignore
 symlinks.  Mind you, this is being explicit in the command, as the default
 is to not follow symlinks.  If you want it to follow symlinks, use the -L
 switch.

 This would modify the command to:
 find -P [dir] -exec chown user:group {} \;


 On Tue, Jun 8, 2010 at 11:57 AM, j...@actionline.com wrote:


 Thanks Dale, Kaia, and Eric ...

 Sincerely appreciate all of your answers. Each one helped.

 I fully realize that entirely too often, I have no idea what I am doing;
 but I just blindly muddle along anyway and somehow, by the grace of God
 and the guidance of so many excellent plug friends, I manage to sort
 things out and happily survive. ;)

 In this case, I learned a bit more from each answer, some of which I
 understand, and some of which I still do not understand. However, I got
 the result that I needed. I just test various commands on a small sample
 and once I eventually get something to work, I apply it further.

 Joe


  I originally wrote:
  While the example commands below work to change permission for either a
  complete system or for a complete directory and all sub-directories,
  what would the syntax be for a similar command to 'chown' (change the
  owner) globally or for a designated directory and and the files and
  subdirectories below it?
 
  find . -type f -print0 | xargs -0 chmod 644
  find . -type d -print0 | xargs -0 chmod 755
 
  find dir -type f -print0 | xargs -0 chmod 644
  find dir -type d -print0 | xargs -0 chmod 744

 Dale wrote:
  Joe, before answering your question, I feel the need to warn you.
 
  If you understood what the above commands do, the answer would be
 obvious
  and you wouldn't have asked the question.  Further, IMHO, unless you
 know
  what each part of the above commands do, you shouldn't use them.  Each
  line has three commands, each of which is readily understandable with
  some effort.
 
  (BTW, none of the above commands change permissions for a complete
 system.
  They only do it recursively for files in a directory or for a directory
  and its subdirectories.)
 
  To change the owner and group for a directory and recursively to its
  files and subdirectories, do:
 
  (1)   chown -R owner:group dir
 
  To change just the owner:
 
  (2)   chown -R owner dir
 
  To change just the group:
 
  (3)   chown -R :group dir
 
  An alternative way (just less efficient) to accomplish (1) is:
 
  (4)   find dir -print0 | xargs -0 chown owner:group
 
  -Dale

 = Previous replies:
 A: Eric wrote: to globally change owner:
 find dir -type f -exec chmod user:group {} \;
 find dir -type d -exec chmod user:group {} \;

 (J: I discovered that 'chmod' in the Eric's example
 should apparently have been 'chown' ... I think.)

 A: kaia.tay...@schwab.com -- To avoid any surprises with links,
 if there are any, do this first:
 find [dir] -type l | more
 Then:
 find [dir] -exec chown user:group {} \;


Yes, I, too, have worked with the regex command line cowboys, (Opps was
that supposed to be a backtick?)?

I would suggest a nice:

tar -cvzf /tmp/safetynet-file.tgz {$filespectree}

You do of course have a nice automated /tmp directory cleaner on your nix of
choice?

If not:

rm /tmp/safetynet*

And also, since I like to remember things I use, so I don't have constantly
recreate the wheel, why not put it all in a standard bin as a script?
-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss

Re: Crackabiltiy of OpenSSL, GPG, bcrypt and scrypt

2010-06-21 Thread Lisa Kachold
For you tree hugger types, this O'Reilly book by John Viega is available
from the Phoenix public library (probably in at the Central Branch on the
5th floor).

http://www.objectgraph.com/img/blog/book2.png


But sadly not autographed!

On Mon, Jun 21, 2010 at 7:38 PM, Tim Bogart timbog...@yahoo.com wrote:

 John Viega is probably one of the leading authorities on the
 vulnerabilities regarding SSL.  I used to have his book (signed of course),
 but that's another story.  For those who may be interested,


 http://www.infibeam.com/Books/info/John-Viega/Network-Security-with-Open-SSL/059600270X.html

 It's an O'Rielly.

 t

 --
 *From:* Lisa Kachold lisakach...@obnosis.com
 *To:* gm5...@gmail.com; Main PLUG discussion list 
 plug-discuss@lists.plug.phoenix.az.us
 *Sent:* Mon, June 21, 2010 7:23:49 PM
 *Subject:* Re: Crackabiltiy of OpenSSL, GPG, bcrypt and scrypt



 On Wed, Jun 9, 2010 at 7:36 AM, gk gm5...@gmail.com wrote:

 I hope I am making an apples to apples comparison.

 I'm not talking about Debian's mess up awhile back. Nor am I talking about
 something that was flying around Debian's mailing list for OpenSSL,
 FUSE/ENCFS and AES ciphers.


 I'm talking overall. Which is the most stable, has the highest probability
 of not be broken in our lifetimes (20 yrs). Mainly I'm trying to center in
 on file management, not email. GPG is good for email, but I find that using
 OpenSSL is actually easier because it is by default installed on *nix boxen,
 AND is VERY VERY easily installed on M$ products compared to the massive
 hoops that have to be done for GPG on the later that even a well versed
 Linux user would be pressed to install right.

 scrypt claims it is much more difficult in its derivations than bcrypt
 which is 448 bit Blowfish. Thereby saying it is harder to crack. However,
 I can not find anything on scrypt that says what type of encryption method
 it uses much less bit value.

 So if you had a face off between OpenSSL, GPG and scrypt for file
 encryption. Let me say bcrypt has some funky responses once in a while to
 extra large files, ie  4gb. Which to use?


 gk

 --
 Remember, it's not that we have something to hide; it's that we have
 nothing to show.

 --Keep tunneling.


 I would have to take the openssl road here!

 Of course, maintaining the most recent stable version and upgrading when
 security issues are found are required of all code or systems tools
 management.

 We are not even going to begin to discuss that entropy remains broken.

 --
 Office: (480)307-8707
 ATT: (503)754-4452
















 ---
 PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
 To subscribe, unsubscribe, or to change your mail settings:
 http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss




-- 
Office: (480)307-8707
ATT: (503)754-4452
---
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss