TESTING - please ignore

[Michael ODonnell]

Debugging postfix - sorry for the noise...

  --M
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Testing....

[Joshua Judson Rosen]

Looks like the list is still working. Had my doubts, for a moment.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Testing direct IO with FIO

[Rodney Tortorich]

I think I figured out my problem.
I wasn't following all the forked processes in my strace correctly.

Using the -ff option I now see the file being opened with the O_DIRECT flag as 
I expected.

-Rodney




 From: Michael ODonnell 
To: gnhlug-discuss@mail.gnhlug.org 
Sent: Monday, January 23, 2012 9:52 PM
Subject: Re: Testing direct IO with FIO
 


Does your strace output show any fcntl() calls?  I believe it's
possible (maybe even necessary?) to set attributes like O_DIRECT
and O_ASYNC using fcntl() as well as during the original open().

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Testing direct IO with FIO

[Michael ODonnell]

Does your strace output show any fcntl() calls?  I believe it's
possible (maybe even necessary?) to set attributes like O_DIRECT
and O_ASYNC using fcntl() as well as during the original open().
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Testing direct IO with FIO

[Rodney Tortorich]

I'm trying to test block layer IO performance using FIO (v1.58 on rhel 5 and 6) 
and I'm not able to verify that the tool is actually performing non-buffered 
I/O.

In my job file I'm turning on the "direct" option on by setting it to 1 and 
I've also tried the "buffered" option as well.

According to the man page:

"direct=bool
  If true, use non-buffered I/O (usually O_DIRECT).  Default: 
false."

I do see a difference in the performance when I run the job with this option 
enabled vs disabled.

However when I strace it, the "O_DIRECT" flag is not set on the open() sys call 
as I would expect.

The open() in both non-buffered I/O and buffered I/O tests look identical, so 
why the difference in performance between the 2 tests?


Anyone have any thoughts or experience using this tool?

-Rodney___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Notes for SLUG 10 May 2010 - Testing web apps

[Benjamin Scott]

  Seven people attended the SLUG[1] meeting on Mon 10 May 2010, titled
"Simulating web users".[2]  Rob showed us some of the stuff he'd been
working on to automate testing of a web application.  It raises an
interesting point -- when your application is a web site, automated
testing is a bit more complicated than a shell script wrapped around
your program.  You have to be a web browser!

[1] http://wiki.gnhlug.org/twiki2/bin/view/Www/SLUG
[2] http://slug.gnhlug.org/Members/rea/SLUG/slug-meetings/simulating-web-users

  Rob briefly demonstrated Selenium[3].  From a distance, it's kind of
like expect[4] for a web browser.  Selenium has several parts.
Selenium IDE is a GUI thing that hooks into Firefox and "records"
actions you take as you browse.  You can then review and modify the
recorded actions.  It has several output formats, most of which a
programming languages (Java, Python, Ruby, others).  The code it
generates consists of calls to the Selenium API, in the language of
your choice.  You can then run that code as a unit test.  The API
calls talk to Selenium RC (Remote Control).  RC is daemon (Java-based)
which plays back the actions you recorded with IDE.  It starts up the
browser you ask for (Firefox, Safari, MSIE) and does what the API
calls say to do.  The browser runs hidden.  It channels the browser
through an HTTP proxy it provides, so that it can inject JavaScript
code to do the "playback".  There's also Selenium Grid, which lets you
run many RCs.

[3] http://seleniumhq.org/
[4] http://expect.nist.gov/

  Rob then moved on to his home-grown solution.  He needed to get
creative because they didn't really have test cases for what they
wanted to test ("load testing with real world usage").  But he did
have a bunch of Apache logs.  The web app is basically "read only"
(it's kind of like a special-purpose Google Maps), so he figured he
could use the Apache web logs to replay what real users have done.
And replay a bunch of them at once to simulate lots of users.  So he
whipped up some Python code.

  First he had to read the Apache logs.  For that, he found an
existing log parser in apachelog[5].  It parses each line into a
dictionary, where the dictionary keys are the Apache log field symbols
(%t for time, %h for client host IP address, etc.).  Rob wasn't
familiar with those, so he wrapped it in a Python class with get
methods.  Then Rob moved on to simulating a web user.  This turned out
to be trickier than it would seem.  For one, Apache only writes the
log entry when the request is finished, so the log order is not
necessarily the order the user did things in.  For another, modern web
browsers makes multiple requests simultaneously.  So Rob had to dive
into multi-threaded programming in Python.  That proved an adventure
in itself.  Unfortunately, my understanding of Python is very limited,
so most of this part was over my head.  It seemed interesting though!

[5] http://code.google.com/p/apachelog/

  Thanks to Rob for once again coming up with an interesting "off the
cuff" presentation.

  See you next month!

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[OL] Re: Wanted - SATA/PATA/USB2 SSD with bad sectors for bcache testing (and offer of bcache presentation)

[Alan Johnson]

I don't think any of ours are bad, but I've got piles of 512GB SSDs at the
moment, and I'm about to order more, so if you would like to do some
benchmarking with lots of parallel SSDs, we might be able to help.  I don't
know if I can let them out of the building since they are supposed to go
into production eventually, but we have plenty of bench space and hardware
at the moment, so if you want to come here and play some day, just let me
know.

I am very interested in this project because we are currently paying Bill M.
some real money just to TRY and setup my "ultimate cloud storage solution"
use layers of Nexenta virtual machines to get ZFS introduced into our Ubuntu
friendly environment.  I am wondering if we could tackle this more simply
with bcache as part of the picture.  I also wonder how bcache would work
with FusionIO in the mix.  We are about to order a couple more of those, so
we should have a window where we can play with them before they go into
production.

Maybe you Bills and I should get together for lunch to see if there is some
way we can help eachother out.  Let me know.
___
Alan Johnson
a...@datdec.com


On Mon, May 10, 2010 at 1:46 PM, William Stearns  wrote:

> Good afternoon, all,
>"Seriously?  He wants _bad_ sectors?" I hear them say.  :-)
>
>I'm working on a linux kernel project that uses SSD's to cache
> normal rotating media hard drives.  bcache is in early development and not
> stable for general use, but the performance numbers are enticing:
>
> * md5sum of small files: 3.5MB/sec off hard drive, 14.5MB/sec off SSD
> cache.
>
> * directory listing of large fragmented tree: 390 seconds off hard drive,
> 202 seconds off SSD cache.
>
> * md5sum of 1.995GB file with 23,522 extents: 251 seconds from HD
> (7.948MB/sec), 82 seconds from SSD cache (24.329MB/sec).
>
>On a side note, I'd be happy to give a talk with a live demo on
> bcache to any gnhlug chapter; get in touch if you have an open month.
>
>As part of the testing, I want to make sure that the code is
> resilient enough to recognize bad sectors on the SSD cache and not
> panic/bug/die.  That requires an SSD with bad sectors.  Size and speed are
> not critical.  I have the ability to connect to sata, pata, and usb.
>Anyone have one?
>
>Before I get inundated with offers, I already have a hard drive
> with underlying bad sectors for that part of the testing.  Come to think
> of it, I probably have 15 to 20 hard drives with issues.  :-)
>Cheers,
>- Bill
>
> ---
>"Power concedes nothing without a demand. It never did, and it
> never will.  Find out just what people will submit to, and you have
> found out the exact amount of injustice and wrong which will be imposed
> upon them; and these will continue until they are resisted with either
> words or blows, or with both.  The limits of tyrants are prescribed by
> the endurance of those whom they oppress."
>-- Frederick Douglass, August 4, 1857
> (Courtesy of Eric S. Raymond)
> --
> William Stearns (wstea...@pobox.com, tools and papers: www.stearns.org)
> Top-notch computer security training at www.sans.org , www.giac.net
> --
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Wanted - SATA/PATA/USB2 SSD with bad sectors for bcache testing (and offer of bcache presentation)

[William Stearns]

Good afternoon, all,
"Seriously?  He wants _bad_ sectors?" I hear them say.  :-)

I'm working on a linux kernel project that uses SSD's to cache 
normal rotating media hard drives.  bcache is in early development and not 
stable for general use, but the performance numbers are enticing:

* md5sum of small files: 3.5MB/sec off hard drive, 14.5MB/sec off SSD 
cache.

* directory listing of large fragmented tree: 390 seconds off hard drive, 
202 seconds off SSD cache.

* md5sum of 1.995GB file with 23,522 extents: 251 seconds from HD 
(7.948MB/sec), 82 seconds from SSD cache (24.329MB/sec).

On a side note, I'd be happy to give a talk with a live demo on 
bcache to any gnhlug chapter; get in touch if you have an open month.

    As part of the testing, I want to make sure that the code is 
resilient enough to recognize bad sectors on the SSD cache and not 
panic/bug/die.  That requires an SSD with bad sectors.  Size and speed are 
not critical.  I have the ability to connect to sata, pata, and usb.
Anyone have one?

Before I get inundated with offers, I already have a hard drive 
with underlying bad sectors for that part of the testing.  Come to think 
of it, I probably have 15 to 20 hard drives with issues.  :-)
Cheers,
- Bill

---
"Power concedes nothing without a demand. It never did, and it
never will.  Find out just what people will submit to, and you have
found out the exact amount of injustice and wrong which will be imposed
upon them; and these will continue until they are resisted with either
words or blows, or with both.  The limits of tyrants are prescribed by
the endurance of those whom they oppress."
-- Frederick Douglass, August 4, 1857
(Courtesy of Eric S. Raymond)
--
William Stearns (wstea...@pobox.com, tools and papers: www.stearns.org)
Top-notch computer security training at www.sans.org , www.giac.net
--
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Bill McGonigle]

On 09/08/2009 08:03 PM, Dan Jenkins wrote:
> The network switches, wireless access points, printers, and 
> computers scattered throughout the buildings, however, are not so 
> protected.

Well, thar's y'er problem.

If you keep your network gear up your recovery scenario will improve
greatly.  Whether it's OSPF, STP, BDU-guard, or whatever, often time
switches will not be ready to send traffic when the computers want it if
everything is brought back up at once.  Then you get machines timing out
because DHCP never came back, and all sorts of boundary conditions
nobody ever bothered to test for.

It's very common to have a little 700VA APC sitting on the floor inside
a wiring closet to keep the switches running through blips.

And, yeah, like Ben said, it's quite odd to have to regularly cut power
to a building for generator testing.  Weekly testing isn't uncommon, but
even in place with BFG's out back, I haven't seen this kind of setup.
Maybe in the days before pervasive computing it wasn't a big deal.
Though, since you need to have UPS'es to let the generators start up
anyway, it probably doesn't matter for the data center.

If the computers are centrally managed, maybe find out how to get a
scheduled shutdown incorporated?  Automatic startup is also offered on
many machines.  I've always advised people to budget an extra $50 for a
desktop to cover the cost of a cheap UPS, though that seems to be more
like $100 now with 'green' power supplies (too high an inrush current
for the cheap-o UPS's - yes, you save 20% on electricity, but it takes
an extra pound of lead for operations ...).

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: b...@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Dave Johnson]

Ben Scott writes:
>   But it's funny, lots of people have disaster stories... it seems
> everyone knows what *not* to do, or what can go wrong... but if you
> ask what you *should* do, and people are less certain.  :)

umm.. ya. speaking of what not to do, don't keep adding load to your
building transformer and not notice this.

Worked at a place where after adding more and more servers and lab
equipment every month, the transformer outside the building was way
overloaded 24/7.

I think it was already scheduled for upgrade, but it wasn't soon
enough.  It started leaking oil into the parking lot one day where
someone noticed it and called the power company.  They got there
really quick and shut it off "right now" before it could fail
spectacularly.

-- 
Dave
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[michael miller]

Sounds like a good explanation, but doesn't fit with my experience.
Several years ago I had a problem with my UPS refusing to let the
generator take over.  It was a high quality (Honda) generator with more
than enough capacity and both 120 and 240 output.  I suspected that the
problem was related to the waveform but was to lazy to troubleshoot the
problem.  I just took the UPS out and let the generator do its job.
Bottom line is that you should actually test your UPS/generator
combination together to make sure that they are compatible.

Mike Miller

On Thu, 2009-09-10 at 08:25 -0400, Ben Scott wrote:
> Bruce accidentally sent this off-list, but said I could forward it
> here for benefit of all...
> 
>   Thanks again, Bruce, for the good info!
> 
> -- Forwarded message --
> From: Bruce Dawson 
> Date: Wed, Sep 9, 2009 at 10:14 PM
> Subject: Re: [OT] Generator testing
> To: Ben Scott 
> 
> Ben Scott wrote:
> >   I know many UPSes don't like the output from some generators, for
> > example -- they stay on battery (which runs down and then drops the
> > load).
> 
> My experience has been this is because the UPS doesn't like the phase
> output of the generator. This can usually be resolved by using a
> generator that has sine wave output. Another (probably easier to find)
> solution is to use a generator that has a 220 socket. Some of the better
> UPSs don't like the phases output by "single-coil" generators, and
> getting a generator with a 220 socket tends to generate a better waveform.
> 
> Note that you don't have to use the 220 receptacle, just find a
> generator that has the capability.
> 
> Keep in mind that generators will tend to raise or drop voltage whenever
> the load changes, however, all of our UPSs (mostly APC) tend to cope
> with that. They'll beep until the generator is able to come back up to
> speed. If the generator doesn't come up to speed, then you're probably
> loading it beyond its capacity - or have a really cheap one that doesn't
> auto-throttle according to the load (or have a governor controlled
> throttle).
> 
> --Bruce
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Frank DiPrete]

Ben Scott wrote:
>   Bruce accidentally sent this off-list, but said I could forward it
> here for benefit of all...
> 
>   Thanks again, Bruce, for the good info!

Thank you for the forward

> 
> -- Forwarded message --
> From: Bruce Dawson 
> Date: Wed, Sep 9, 2009 at 10:14 PM
> Subject: Re: [OT] Generator testing
> To: Ben Scott 
> 
> Ben Scott wrote:
>>   I know many UPSes don't like the output from some generators, for
>> example -- they stay on battery (which runs down and then drops the
>> load).
> 
> My experience has been this is because the UPS doesn't like the phase
> output of the generator. This can usually be resolved by using a
> generator that has sine wave output. Another (probably easier to find)
> solution is to use a generator that has a 220 socket. Some of the better
> UPSs don't like the phases output by "single-coil" generators, and
> getting a generator with a 220 socket tends to generate a better waveform.
> 
> Note that you don't have to use the 220 receptacle, just find a
> generator that has the capability.
> 
> Keep in mind that generators will tend to raise or drop voltage whenever
> the load changes, however, all of our UPSs (mostly APC) tend to cope
> with that. They'll beep until the generator is able to come back up to
> speed. If the generator doesn't come up to speed, then you're probably
> loading it beyond its capacity - or have a really cheap one that doesn't
> auto-throttle according to the load (or have a governor controlled
> throttle).
> 
> --Bruce


I have a generac/siemens 13kva generator wired through a transfer switch 
to my 150A service. What Bruce states above is the case with this setup. 
The generator puts out slightly less that 110 volts at 58Hz at the low 
point and when put under heavier load comes closer to 60hz, 110.

I can hear the rpm's of the generator fluctuating when this happens.
Load increases, voltage drops slightly, governor increases the throttle.
This is normal and expected behavior from the generator.

When I had the system installed I was informed that I would have to 
select UPS units that can condition power within a window of 
voltage/power/frequency input.

I am using an APC smart ups on my rack that can deal with this quite 
well with minimal switching from battery to outlet.

The good news is that the generator comes up in 20 seconds so the UPS 
capacity does not have to be hours, but minutes of run time for the load 
to deal with the 20 seconds of down time before the transfer switch 
changes the power source from utility to generator; and the few seconds 
of fluctuation out of the UPS's input tolerance that happens during run 
time.

I had a few cheapo UPS units that have zero input tolerance and can be 
used as door stops.

The ice storm last winter was a 5 day "test".




> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Ben Scott]

  Bruce accidentally sent this off-list, but said I could forward it
here for benefit of all...

  Thanks again, Bruce, for the good info!

-- Forwarded message --
From: Bruce Dawson 
Date: Wed, Sep 9, 2009 at 10:14 PM
Subject: Re: [OT] Generator testing
To: Ben Scott 

Ben Scott wrote:
>   I know many UPSes don't like the output from some generators, for
> example -- they stay on battery (which runs down and then drops the
> load).

My experience has been this is because the UPS doesn't like the phase
output of the generator. This can usually be resolved by using a
generator that has sine wave output. Another (probably easier to find)
solution is to use a generator that has a 220 socket. Some of the better
UPSs don't like the phases output by "single-coil" generators, and
getting a generator with a 220 socket tends to generate a better waveform.

Note that you don't have to use the 220 receptacle, just find a
generator that has the capability.

Keep in mind that generators will tend to raise or drop voltage whenever
the load changes, however, all of our UPSs (mostly APC) tend to cope
with that. They'll beep until the generator is able to come back up to
speed. If the generator doesn't come up to speed, then you're probably
loading it beyond its capacity - or have a really cheap one that doesn't
auto-throttle according to the load (or have a governor controlled
throttle).

--Bruce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Ben Scott]

On Wed, Sep 9, 2009 at 2:29 PM, Jerry Feldman  wrote:
> I worked at a facility that did not have a backup generator but did have
> 2 separate power lines from 2 different power companies. Of course that
> does not help when the grid fails.

  There's usually a single-point-of-failure.

  Within the past 18 months or so, a big datacenter went out because a
transformer in their power vault exploded.  It knocked down the wall
with all the electrical panels on it, sheering off all the conduits
and wires.  I saw a picture of their parking lot a week later; there
must have 20 generator trucks parked outside, and enough cable to
reach half-way to the moon.

  Another scenario I saw put forth on NANOG: "Can your disaster
recovery plan cope with a fire marshal pointing at your data center
and saying, 'Turn that off.  *Right now*.'?"  (Fire fighters are real
touchy about energized equipment.  (Understandably.))

  But it's funny, lots of people have disaster stories... it seems
everyone knows what *not* to do, or what can go wrong... but if you
ask what you *should* do, and people are less certain.  :)

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Jerry Feldman]

I worked at a facility that did not have a backup generator but did have
2 separate power lines from 2 different power companies. Of course that
does not help when the grid fails.

Jerry



signature.asc
Description: OpenPGP digital signature
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Dan Jenkins]

Ben Scott wrote:
> I know many UPSes don't like the output from some generators, for
> example -- they stay on battery (which runs down and then drops the
> load).  So I know just going to Home Depot and buying something off
> the shelf is probabbly a bad idea.  But I wouldn't know what to look
> for if I was asked to review a proposal.
>   
I had not thought of that. Even though the UPSes are keeping the servers 
up, I don't know if the UPSes consider the generator power good. I'll 
have to check next week. We had proposed putting tiny UPSes on the 
network switches and access points so as to keep that stuff working, but 
a tiny UPS might not keep up devices for the 10 to 15 minute outage.

Thanks everyone for the interesting discussion I've seen so far.

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Ben Scott]

On Wed, Sep 9, 2009 at 11:17 AM, Hewitt_Tech  wrote:
> When I was in the Army Signal Core I worked
> at communications facilities that used battery strings (48V) that
> provided station power by feeding very large inverters.

  That's similar how US commercial telco COs (central offices) do
things.  Except they just design most of their equipment (including
landline phones) to run off 48 VDC and so don't need as much inverter
capacity.  Under normal operations, they just keep the batteries
topped off from city power.  If city power fails, the batteries just
start discharging -- there are no transfer issues because there is no
transfer.  Then they have on-site generators to start recharging if
city power doesn't come back quickly.  They also use two battery
systems in each building, with two sets of wiring, each on opposite
sides of the walls and racks, so if something goes wrong and blows up
one battery system, things keep running.  It's a very robust design,
and a rather different mindset from what one often sees today.

  In my request for stories, I was especially interested in AC
generators and transfer systems, because that's something I don't have
much knowledge of.  UPSes you can buy at Wal-Mart these days.  ;-)
There's been a little (mostly idle) talk of a generator for our front
office at $DAYJOB, though, and I know next to nothing about the
practical aspects.

  I know many UPSes don't like the output from some generators, for
example -- they stay on battery (which runs down and then drops the
load).  So I know just going to Home Depot and buying something off
the shelf is probabbly a bad idea.  But I wouldn't know what to look
for if I was asked to review a proposal.

  Pointers to good websites, books, etc., are also welcomed.  :)

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Hewitt_Tech]

Tom Buskey wrote:
> 
> 
> On Wed, Sep 9, 2009 at 7:30 AM, Jerry Feldman  > wrote:
> 
> On 09/08/2009 10:18 PM, Ben Scott wrote:
>  >   FWIW, I find this topic fascinating, and quite possibly of interest
>  > to my professional career, so I'd like to hear the stories, too.  :)
>  >
> 
> 
> We have a lab where I am that was killing a hard drive every week.  We 
> put the systems on UPS and haven't had a failure since.
> 
> We also had problems in the DC during outages because the AC was not on 
> the generator.  After an hour w/o AC, the DC would start to overheat & 
> we had to shutdown systems anyways.
> 
> I heard a story about a generator that passed its periodic tests but 
> failed an outage because the fuel pump was not on the generator.
> 
> 
> 
> 
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Not quite a war story ;^). When I was in the Army Signal Core I worked 
at communications facilities that used battery strings (48V) that 
provided station power by feeding very large inverters. In the event of 
a commercial power fail one of two 30 kw diesel generators would auto 
start and provide the missing AC. The station required approximately 15 
kw to maintain operations but the batteries alone could provide at least 
24 hours of operation.

We had a second site with a similar configuration. That site had an AC 
power failure but the diesel generator didn't start correctly. At that 
point the station actually ran for almost 3 days before finally dropping 
off line. Of course at that point all hell broke loose. ;^)

-Alex

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Tom Buskey]

On Wed, Sep 9, 2009 at 7:30 AM, Jerry Feldman  wrote:

> On 09/08/2009 10:18 PM, Ben Scott wrote:
> >   FWIW, I find this topic fascinating, and quite possibly of interest
> > to my professional career, so I'd like to hear the stories, too.  :)
> >
>
>
We have a lab where I am that was killing a hard drive every week.  We put
the systems on UPS and haven't had a failure since.

We also had problems in the DC during outages because the AC was not on the
generator.  After an hour w/o AC, the DC would start to overheat & we had to
shutdown systems anyways.

I heard a story about a generator that passed its periodic tests but failed
an outage because the fuel pump was not on the generator.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Jerry Feldman]

On 09/08/2009 10:18 PM, Ben Scott wrote:
>   FWIW, I find this topic fascinating, and quite possibly of interest
> to my professional career, so I'd like to hear the stories, too.  :)
>   
One war story. I was a programmer at Burger King a number of years ago
(assembler on PDP-8 BTW). We had 2 diesel generators sitting outside the
building to give us power when the power failed (DUH). One stormy day,
we were in the conference room overlooking the generators, and they
received a direct lightning strike that took out both the generators and
the power.

-- 
Jerry Feldman 
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846




signature.asc
Description: OpenPGP digital signature
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Ben Scott]

On Tue, Sep 8, 2009 at 9:55 PM, Bruce Dawson wrote:
> I've got lots of practical experience (and horror stories) if you're
> interested in hearing about them off-list.

  FWIW, I find this topic fascinating, and quite possibly of interest
to my professional career, so I'd like to hear the stories, too.  :)
Whether they should be on this list or elsewhere, I dunno.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Ben Scott]

On Tue, Sep 8, 2009 at 8:03 PM, Dan Jenkins wrote:
> The unusual thing, to me, about it is that they test it in the middle of
> every week during normal work hours. First thing in the morning, the
> power in all the buildings goes off for about 20-60 seconds when they
> switch to the generator, and then does it again 5-10 minutes later when
> they switch back.

  I have little direct experience, but I can describe what I've been told:

  Generators can be tested in two ways, no-load and loaded.
Additionally, loaded testing can be real or simulated.

  A no-load test just tests the engine (prime mover) and spins all the
moving parts; it doesn't actually test power generating capability,
transfer switches, etc.  It is sometimes called "exercising".  It's
still a very useful thing to do, because the moving parts are usually
the most likely to fail, and they'll also tend to stick if you don't
run them regularly.

  A loaded test actually puts a load on the generator (duh).  A
simulated load puts a dummy load on the generator, to make sure it can
actually generate power, and that the wiring to the switch point is
good.  It doesn't test your live transfer capability, nor prove that
everything will work right "for real".  And obviously, a real load
test is what you're doing -- see if the generator can power the real
load under (supposedly) real conditions.

  The do-it-yourself automatic-generator-in-a-box kits I've seen for
home use advertise the capability to exercise themselves
automatically, once per week.  Loaded testing is entirely up to the
home owner.

  A big datacenter I took a tour of once (hi Ted!) had truck-sized
generators.  They did no-load tests every other week, IIRC.  They did
simulated load testing once a year, which involved the generator
service company trucking in a huge resistor bank.  I don't know if
they did any periodic real-load tests, but the trucking in of a dummy
load suggests not.

  I've worked in one or two other buildings that supposedly had backup
generator capability.

  In that limited experience, I've *NEVER* heard of shutting the whole
building down once per week to test the generator.  Talk about missing
the fscking point.  Unless your power utility is so unreliable that
they have outages more than weekly, you're actually better off without
that generator at all.

  Possibly relevant:

  The thing that selects "public utility power" vs "local generator"
is called a transfer switch.

  Cheaper transfer switches do a break-before-make, keeping everything
in isolation, but meaning you drop the load at least briefly during
the switch.  Cheap, safe, easy.

  There are also break-before-make transfer switches, which don't drop
the load, but also have to be sophisticated enough to keep Bad Things
from happening when both sources are connected at once.  You don't
want your generator feeding back into the grid, or the linemen trying
to fix your utility outage can be killed.  You also don't want your
generator trying to fight the utility for control of phase and
frequency, because your generator will lose.  How exactly these
switches accomplish this is pure magic to me.

  I imagine if you have the later kind of transfer switch, real-load
testing is easier.

  DISCLAIMER: Everything I say could be a total lie.

> The servers, all but one running Linux (to bring this
> slightly on-topic), are protected by UPSes, so they aren't directly
> affected.

  For most UPSes once encounters running computers, doing that every
week will significantly shorten the battery lifetime, and possibly
that of the power electronics as well.

> They have noticed it takes the network awhile to operate normally after
> this weekly event. Not surprisingly with a flood of DHCP requests and
> SMB network convergence happening when several hundred computers
> are turned on.

  Indeed.

  If you're not already doing so, set up WINS servers, and configure
your NetBIOS node type to 0x2 (WINS only, AKA P-node, AKA peer node).
This will at least significantly reduce broadcast traffic due to name
resolution.

  You can also disable NetBIOS browsing.  That will reduce traffic
from browser elections and browse list maintenance.  However, you'll
lose the ability to view active NetBIOS nodes -- i.e., "NET VIEW" and
"Network Neighborhood" will be empty.

> It seems wrong to me & to the maintenance director, however,
> the company which installed the equipment says this is normal operation.

  Talk to the company's competitors and see what they say.

> Someone involved with the project implied it is a legal requirement in
> some manner.

  Electrical and safety codes are a maze of twisty passages, all
similar but none alike.  A lot of stuff that someone says you can or
can't do can often be done in a different

Re: [OT] Generator testing

[Bruce Dawson]

Dan Jenkins wrote:
> This is only tangentially related to Linux, but I'd like to gather your 
> thoughts.
>
> We have a client who installed a backup generator for their buildings 
> some months ago, which is all to the good.
>
> The unusual thing, to me, about it is that they test it in the middle of 
> every week during normal work hours. First thing in the morning, the 
> power in all the buildings goes off for about 20-60 seconds when they 
> switch to the generator, and then does it again 5-10 minutes later when 
> they switch back. The servers, all but one running Linux (to bring this 
> slightly on-topic), are protected by UPSes, so they aren't directly 
> affected. The network switches, wireless access points, printers, and 
> computers scattered throughout the buildings, however, are not so 
> protected. Everyone is supposed to turn off their equipment Tuesday 
> night, but often individuals forget. They have noticed it takes the 
> network awhile to operate normally after this weekly event. Not 
> surprisingly with a flood of DHCP requests and SMB network convergence 
> happening when several hundred computers are turned on. Some of the 
> network switches and access points require a power cycle. We have seen a 
> slight increase in equipment failures, largely among the oldest devices. 
> We have proposed a plethora of UPSes to support the network devices, 
> however, that has not yet been approved, and may not be until next year. 
> We have also requested a less frequent test cycle and relocation to a 
> weekend, so far to no avail.
>
> My question, is it normal to test a generator weekly, during operating 
> hours, and is it normal to shutdown all the power in the buildings to 
> test it? It seems wrong to me & to the maintenance director, however, 
> the company which installed the equipment says this is normal operation. 
> Someone involved with the project implied it is a legal requirement in 
> some manner. Does any of that jibe with others experiences?
>
> Thanks enormously for any feedback.
>   
Its more a function of their ATS (Automatic Transfer Switch). For
example, our ATS (for the 50KW generator we have here on the farm) has a
weekly clock (that does not understand daylight savings time, sigh) to
perform the automatic exercising.

But, be glad that they are dumping the power for 20-60 seconds during
the "exercise interval"! It may be inconvenient, but if the power was
not dumped, there will be a "phase change" during the switchover that
will [eventually] destroy all the motors that are on the generator
circuit. (For motors, think: freezers, fans,
pumps, ...) I've also heard that those phase changes are hell on solid
state power supplies, but don't have any solid direct evidence.

If they had synchros on the generators, then that would make the
transfer nearly seamless. However, you're talking about a much more
expensive genset. Most gensets smaller than 100KW don't have phase sync
abilities, and those that do require additional expensive equipment to
take advantage of them.

BTW, I haven't found a line-interactive UPS that will protect against
generator initiated phase changes. Just dumping the power for a few
seconds is the cheapest most practical approach to protecting equipment
against phase shifts.

However, I did find something odd about what you said... Evidently the
test period is only "5-10 minutes". I would be a little concerned that
the genset has had time to warm up in that period. We've set our test
period to be 1 hour and during "prime time" to put as much of a load on
the genset as possible. (Most gensets hate variable loads, and the best
way to keep them "nimble" is to exercise them with a big load.)

Another thing they should be aware of is that the fuel tank is heated.
We've had ice crystals form in the fuel filter, thus clogging it, and
preventing the genset from properly activating during a real power fail
(or exercises). This was a real problem to diagnose because by the time
we got it running, the ice had melted and the generator would activate
flawlessly. I never would have figured out the problem unless something
similar happened on one of our tractors and the tractor repair shop told
me to check on this.

I've got lots of practical experience (and horror stories) if you're
interested in hearing about them off-list.

--Bruce
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Michael ODonnell]

FWIW: I work at a site where we share a building with an ISP/colo vendor
with 3 big diesel generators (each in its own shipping-container sized
enclosure and so powerful they require an automobile-sized resistive
load to dump their juice into during testing) out front plus at least one
slightly smaller unit out back and AFAICT they test those units *maybe*
once every couple of months, if that.  Weekly testing sounds excessive...
 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: [OT] Generator testing

[Alex Hewitt]

Dan Jenkins wrote:
> This is only tangentially related to Linux, but I'd like to gather your 
> thoughts.
>
> We have a client who installed a backup generator for their buildings 
> some months ago, which is all to the good.
>
> The unusual thing, to me, about it is that they test it in the middle of 
> every week during normal work hours. First thing in the morning, the 
> power in all the buildings goes off for about 20-60 seconds when they 
> switch to the generator, and then does it again 5-10 minutes later when 
> they switch back. The servers, all but one running Linux (to bring this 
> slightly on-topic), are protected by UPSes, so they aren't directly 
> affected. The network switches, wireless access points, printers, and 
> computers scattered throughout the buildings, however, are not so 
> protected. Everyone is supposed to turn off their equipment Tuesday 
> night, but often individuals forget. They have noticed it takes the 
> network awhile to operate normally after this weekly event. Not 
> surprisingly with a flood of DHCP requests and SMB network convergence 
> happening when several hundred computers are turned on. Some of the 
> network switches and access points require a power cycle. We have seen a 
> slight increase in equipment failures, largely among the oldest devices. 
> We have proposed a plethora of UPSes to support the network devices, 
> however, that has not yet been approved, and may not be until next year. 
> We have also requested a less frequent test cycle and relocation to a 
> weekend, so far to no avail.
>
> My question, is it normal to test a generator weekly, during operating 
> hours, and is it normal to shutdown all the power in the buildings to 
> test it? It seems wrong to me & to the maintenance director, however, 
> the company which installed the equipment says this is normal operation. 
> Someone involved with the project implied it is a legal requirement in 
> some manner. Does any of that jibe with others experiences?
>
> Thanks enormously for any feedback.
>
> --
> Dan Jenkins, Rastech Inc., Bedford, NH, 1-603-206-9951
> *** IT Support for 30 years
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>   

I have one medical client that does exactly what you  are describing. I 
believe they are mandated by a state of New Hampshire  Health and Human 
Services regulation to perform their generator testing during the day on 
weekdays. In their case they have heavy duty UPSs to carry their load.  
I know exactly where all the UPSs are located because they had a failure 
and asked me  to  figure out how to fix the problem. The UPSs at the 
time were almost 10 years old and overdue for replacement.

-Alex

P.S. Most of their computer resources are not connected to the 
generators/UPSs which are used to keep OR lights and equipment on.


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[OT] Generator testing

[Dan Jenkins]

This is only tangentially related to Linux, but I'd like to gather your 
thoughts.

We have a client who installed a backup generator for their buildings 
some months ago, which is all to the good.

The unusual thing, to me, about it is that they test it in the middle of 
every week during normal work hours. First thing in the morning, the 
power in all the buildings goes off for about 20-60 seconds when they 
switch to the generator, and then does it again 5-10 minutes later when 
they switch back. The servers, all but one running Linux (to bring this 
slightly on-topic), are protected by UPSes, so they aren't directly 
affected. The network switches, wireless access points, printers, and 
computers scattered throughout the buildings, however, are not so 
protected. Everyone is supposed to turn off their equipment Tuesday 
night, but often individuals forget. They have noticed it takes the 
network awhile to operate normally after this weekly event. Not 
surprisingly with a flood of DHCP requests and SMB network convergence 
happening when several hundred computers are turned on. Some of the 
network switches and access points require a power cycle. We have seen a 
slight increase in equipment failures, largely among the oldest devices. 
We have proposed a plethora of UPSes to support the network devices, 
however, that has not yet been approved, and may not be until next year. 
We have also requested a less frequent test cycle and relocation to a 
weekend, so far to no avail.

My question, is it normal to test a generator weekly, during operating 
hours, and is it normal to shutdown all the power in the buildings to 
test it? It seems wrong to me & to the maintenance director, however, 
the company which installed the equipment says this is normal operation. 
Someone involved with the project implied it is a legal requirement in 
some manner. Does any of that jibe with others experiences?

Thanks enormously for any feedback.

--
Dan Jenkins, Rastech Inc., Bedford, NH, 1-603-206-9951
*** IT Support for 30 years

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

in-store Laptop testing (was Re: buying a laptop either bare or with Ubuntu)

[Alan Johnson]

On Thu, Jan 22, 2009 at 3:41 PM, Jerry Feldman  wrote:

> On 01/22/2009 03:02 PM, Ben Scott wrote:
>
>>  Can the proprietary driver packages be copied to a separate USB
>> flash drive, and then installed into the in-RAM "live" system?
>>
>>
> The simple answer is yes. What you would need to do is to is to open up the
> iso, copy in the appropriate drivers or packages, then make a new iso, and
> either burn a new CD or USB. You could simply grab the appropriate .rpm or
> .deb files to install by hand. Knoppix has a good tutorial on how to
> customize, but since you don't know the target system, just copy in the
> appropriate packages and install them after boot.
>

Has any one played with the "Make a USB Startup Disk" tool in Ubuntu 8.10?
I think it just showed up when I upgraded from 8.04 but maybe I installed it
a while ago and forgot.  Find it Under System > Administration > Create a
USB startup disk.  It looks pretty sweet.  Could be just the thing for
speedier testing and installing propritary drivers.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[GNHLUG] [DLSLUG-Announce] TONIGHT: JUnit - A Unit Testing Framework for Java

[Bill McGonigle]

***
  Dartmouth-Lake Sunapee Linux User Group
   http://dlslug.org/
  a chapter of GNHLUG - http://gnhlug.org
***

The next regular monthly meeting of the DLSLUG will be held:

Thursday, July 3rd, 7-9PM
at:   Dartmouth College, Haldeman Room 041

 All are welcome, free of charge.

 Agenda

7:00  Sign-in, networking

7:15  Introductory remarks

7:20  JUnit - A Unit Testing Framework for Java
 presented by Roger Trussell

   JUnit is a class library that facilitates unit testing for
   Java classes. Unit testing helps programmers to test
   individual classes and methods. Many programmers use unit
   testing as part of agile software techniques and extreme
   programming. As programmers write unit tests for their code,
   they may discover the need for software design changes as
   well as problems with individual methods and classes. Roger
   will present JUnit as it applies to class libraries and
   Swing/AWT applications using both NetBeans and Eclipse. He
   will present ways to store test parameters in XML. As time
   permits, Roger will cover unit testing for simple J2EE
   applications.

   Roger Trussell is a programmer with over five years of
   experience in a variety of roles for health care, software,
   research, and manufacturing environments. He has worked at
   many companies throughout the Upper Valley, including DHMC,
   ISEE Systems, and Timken Aerospace. Roger holds a Bachelor of
   Science degree in Computer Science from Rensselaer
   Polytechnic Institute. One of Roger's main interests is
   bridging the gap between programmers and end-users.

8:50  Roundtable Exchange - where the attendees can make
 announcements or ask a linux question of the group.

-

   Driving Directions

   Please see the website for links to driving directions.


  Refreshments

   We do not yet have a refreshment sponsor for this event.
   Contact me if you'd like to volunteer.  Your employer may
   be interested.  All sponsors are acknowledged during the
   meeting and on the website.

 RSVP

   RSVP by replying to this e-mail so we can give any
   refreshment sponsor a count.

  Mailing Lists

   There are two primary mailman lists set up for DLSLUG, an
   Announce list and a Discuss list. Please sign up for the
   Announce list (moderated, low-volume) to stay apprised of
   the group's activities and the Discuss list (unmoderated)
   for group discussion. Links to the mailing lists are on the
   webpage.

Tell Your Friends

   Please pass this announcement along to anyone else who may
   be interested.


-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

___
DLSLUG-Announce mailing list
[EMAIL PROTECTED]
http://dlslug.org/mailman/listinfo/dlslug-announce
___
gnhlug-announce mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[GNHLUG] [DLSLUG-Announce] JUnit - A Unit Testing Framework for Java

[Bill McGonigle]

***
  Dartmouth-Lake Sunapee Linux User Group
   http://dlslug.org/
  a chapter of GNHLUG - http://gnhlug.org
***

The next regular monthly meeting of the DLSLUG will be held:

Thursday, July 3rd, 7-9PM
at:   Dartmouth College, Haldeman Room 041

 All are welcome, free of charge.

 Agenda

7:00  Sign-in, networking

7:15  Introductory remarks

7:20  JUnit - A Unit Testing Framework for Java
 presented by Roger Trussell

   JUnit is a class library that facilitates unit testing for
   Java classes. Unit testing helps programmers to test
   individual classes and methods. Many programmers use unit
   testing as part of agile software techniques and extreme
   programming. As programmers write unit tests for their code,
   they may discover the need for software design changes as
   well as problems with individual methods and classes. Roger
   will present JUnit as it applies to class libraries and
   Swing/AWT applications using both NetBeans and Eclipse. He
   will present ways to store test parameters in XML. As time
   permits, Roger will cover unit testing for simple J2EE
   applications.

   Roger Trussell is a programmer with over five years of
   experience in a variety of roles for health care, software,
   research, and manufacturing environments. He has worked at
   many companies throughout the Upper Valley, including DHMC,
   ISEE Systems, and Timken Aerospace. Roger holds a Bachelor of
   Science degree in Computer Science from Rensselaer
   Polytechnic Institute. One of Roger's main interests is
   bridging the gap between programmers and end-users.

8:50  Roundtable Exchange - where the attendees can make
 announcements or ask a linux question of the group.

-

   Driving Directions

   Please see the website for links to driving directions.


  Refreshments

   We do not yet have a refreshment sponsor for this event.
   Contact me if you'd like to volunteer.  Your employer may
   be interested.  All sponsors are acknowledged during the
   meeting and on the website.

 RSVP

   RSVP by replying to this e-mail so we can give any
   refreshment sponsor a count.

  Mailing Lists

   There are two primary mailman lists set up for DLSLUG, an
   Announce list and a Discuss list. Please sign up for the
   Announce list (moderated, low-volume) to stay apprised of
   the group's activities and the Discuss list (unmoderated)
   for group discussion. Links to the mailing lists are on the
   webpage.

Tell Your Friends

   Please pass this announcement along to anyone else who may
   be interested.


-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf



___
DLSLUG-Announce mailing list
[EMAIL PROTECTED]
http://dlslug.org/mailman/listinfo/dlslug-announce
___
gnhlug-announce mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

[GNHLUG] [DLSLUG-Announce] JUnit - A Unit Testing Framework for Java

[Bill McGonigle]

***
  Dartmouth-Lake Sunapee Linux User Group
   http://dlslug.org/
  a chapter of GNHLUG - http://gnhlug.org
***

The next regular monthly meeting of the DLSLUG will be held:

Thursday, July 3rd, 7-9PM
at:   Dartmouth College, Room TBA

 All are welcome, free of charge.

 Agenda

7:00  Sign-in, networking

7:15  Introductory remarks

7:20  JUnit - A Unit Testing Framework for Java
 presented by Roger Trussell

   JUnit is a class library that facilitates unit testing for
   Java classes. Unit testing helps programmers to test
   individual classes and methods. Many programmers use unit
   testing as part of agile software techniques and extreme
   programming. As programmers write unit tests for their code,
   they may discover the need for software design changes as
   well as problems with individual methods and classes. Roger
   will present JUnit as it applies to class libraries and
   Swing/AWT applications using both NetBeans and Eclipse. He
   will present ways to store test parameters in XML. As time
   permits, Roger will cover unit testing for simple J2EE
   applications.

8:50  Roundtable Exchange - where the attendees can make
 announcements or ask a linux question of the group.

-

   Driving Directions

   Please see the website for links to driving directions.


  Refreshments

   We do not yet have a refreshment sponsor for this event.
   Contact me if you'd like to volunteer.  Your employer may
   be interested.  All sponsors are acknowledged during the
   meeting and on the website.

 RSVP

   RSVP by replying to this e-mail so we can give any
   refreshment sponsor a count.

  Mailing Lists

   There are two primary mailman lists set up for DLSLUG, an
   Announce list and a Discuss list. Please sign up for the
   Announce list (moderated, low-volume) to stay apprised of
   the group's activities and the Discuss list (unmoderated)
   for group discussion. Links to the mailing lists are on the
   webpage.

Tell Your Friends

   Please pass this announcement along to anyone else who may
   be interested.


-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

___
DLSLUG-Announce mailing list
[EMAIL PROTECTED]
http://dlslug.org/mailman/listinfo/dlslug-announce
___
gnhlug-announce mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-announce/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Testing

[Paul Lussier]

"Travis Roy" <[EMAIL PROTECTED]> writes:

> Just a test

Sorry, you failed... This message was not compiant with the new
X-Visualsly-Appealing-And-Easy-To-Sort-On header rule recently
instituted for this list.

-- 
Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Testing

[Travis Roy]

Just a test

--
Travis Roy
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Network testing and latency

[Paul Lussier]

"Tom Buskey" <[EMAIL PROTECTED]> writes:

> Just saw an ad for http://simena.net/sys which sells a box to do this.

And just received this information upon contacting them:

  Prices range from $9,500 (NE500) to $45,000 (NE3000).  

They mentioned possible discounts, but I didn't inquire about them...
-- 

Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Bill McGonigle]

On Mar 7, 2006, at 16:08, Paul Lussier wrote:


We have a scenario where we've only ever tested our product
over high-speed LAN connections (100MB and GigE).  However, we have
some customers using it over T1 connections, so we need to start
testing this scenario.


I was going to implement nistnet for a client:

  http://www-x.antd.nist.gov/nistnet/

before their project got cut, but it was for that same purpose and 
looked like the right tool for the job.


-Bill

-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Dave Johnson]

Paul Lussier writes:
> Dave Johnson <[EMAIL PROTECTED]> writes:
> 
> > Note that as mentioned before, limiting bandwidth and introducing
> > latency and/or jitter are different things.
> >
> > If you want to simulate a bandwidth limited link you need to both
> > limit bandwidth and queue packets.  If you simply drop and don't queue
> > then there is no possibility of latency.
> >
> > Latency and jitter are side effects due to queuing prior to the
> > bandwidth limited hop.  Protocols such as TCP are designed to avoid
> > introducing latency when a slow link is in the path.
> >
> > Anyway, onto the implementation.
> >
> > Below script limits bandwidth in both directions when forwarding
> > through two interfaces.  Note you'll need to setup the appropriate
> > interfaces and routes.  Each side has it's own bandwidth and queue
> > with a max size in bytes.  This is equivilant to a full-duplex T1
> > pipe using a linux box and 2 ethernet interfaces representing the two
> > endpoints of the T1.
> 
> Dave, does this add jitter as well?  I assume that since you're
> queueing, it does to some extent.  Would it also be wise to inject
> traffic on the simulated T1 connection by having other hosts
> communicating as well?  For example I could have 1 linux system in
> between 2 switches, on which were several other systems all
> communicating with each other doing things like generating web
> requests, copying large files, etc.
> 
> It seems this approach would add to the randomness of the connection
> to some extent, and increase both the latency and jitter experienced
> by the 2 systems we're really trying to test.
> 
> Thanks again!
> 

Latency and jitter due to queuing will be accurate, however the only
thing this won't do is introduce inherant latency due to link speed,
distance, etc...

Sending 1500 bytes over a T1 takes 7.8ms plus forwarding delays,
distance, etc...  If you chain multiple connections together you've
got even more.  The TC setup will forward each packet as fast as
possible, just introduce delays between them to simulate a bandwidth
limit.

In any case if you want a 'real-world' experiance yuo'll need to send
other stuff over the link at the same time as your test.  TCP
connections are easy. If you want to bring the link to a crawl you can
use my UDP network test tool to send packets over the link at any rate:

http://davej.org/programs/untt/

# server listening on port 1
./untt -l -v -p 1

# client sending 400 byte packets at 4mbps (uni-directional)
./untt -vv -p 1 -s 400 -r 4000 -c 100 192.168.11.2


The more bursts the more jitter, the more input the more latency.

Also note the queue size will directly relate to the max latency
because bandwidth is fixed.  The 256KB gives a max latency of
1.333 seconds each direction.

Flooding the link with a constant 4mbps above fills one of the queues
in just seconds and we reach max latency in no time:

64 bytes from 192.168.11.2: icmp_seq=161 ttl=63 time=1350 ms
64 bytes from 192.168.11.2: icmp_seq=162 ttl=63 time=1345 ms
64 bytes from 192.168.11.2: icmp_seq=163 ttl=63 time=1353 ms
64 bytes from 192.168.11.2: icmp_seq=164 ttl=63 time=1348 ms
64 bytes from 192.168.11.2: icmp_seq=165 ttl=63 time=1349 ms
64 bytes from 192.168.11.2: icmp_seq=166 ttl=63 time=1356 ms
64 bytes from 192.168.11.2: icmp_seq=167 ttl=63 time=1350 ms
64 bytes from 192.168.11.2: icmp_seq=168 ttl=63 time=1350 ms


-- 
Dave

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Dave Johnson]

Kevin D. Clark writes:
> 
> Dave Johnson writes:
> 
> > Latency and jitter are side effects due to queuing prior to the
> > bandwidth limited hop. 
> 
> I think that latency has more to do with your transmission medium.
> And I think that jitter has more to do with contention.

Ya, I meant to say queuing introduces jitter and latency.  The
transmission delay of the medium adds latency regardless of
congestion.



> > Protocols such as TCP are designed to avoid
> > introducing latency when a slow link is in the path.
> 
> I think that the design of TCP more has to do with using the network
> efficiently and with operating reliably in the presence of congestion.
> 
> I'm not sure how TCP is designed to avoid intoducing latency.  The
> protocol tries to operate reliably but doesn't really make any
> guarantees that the bytestream will make it to the destination by a
> certain time.

Should have said avoid introducing excessive congestion. Latency is a
side-effect of that.

-- 
Dave

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Kevin D. Clark]

Dave Johnson writes:

> Latency and jitter are side effects due to queuing prior to the
> bandwidth limited hop. 

I think that latency has more to do with your transmission medium.
And I think that jitter has more to do with contention.

> Protocols such as TCP are designed to avoid
> introducing latency when a slow link is in the path.

I think that the design of TCP more has to do with using the network
efficiently and with operating reliably in the presence of congestion.

I'm not sure how TCP is designed to avoid intoducing latency.  The
protocol tries to operate reliably but doesn't really make any
guarantees that the bytestream will make it to the destination by a
certain time.

Thanks for reminding me about tc!

Regards,

--kevin
-- 
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
   -- Tom Waits

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Paul Lussier]

Dave Johnson <[EMAIL PROTECTED]> writes:

> Note that as mentioned before, limiting bandwidth and introducing
> latency and/or jitter are different things.
>
> If you want to simulate a bandwidth limited link you need to both
> limit bandwidth and queue packets.  If you simply drop and don't queue
> then there is no possibility of latency.
>
> Latency and jitter are side effects due to queuing prior to the
> bandwidth limited hop.  Protocols such as TCP are designed to avoid
> introducing latency when a slow link is in the path.
>
> Anyway, onto the implementation.
>
> Below script limits bandwidth in both directions when forwarding
> through two interfaces.  Note you'll need to setup the appropriate
> interfaces and routes.  Each side has it's own bandwidth and queue
> with a max size in bytes.  This is equivilant to a full-duplex T1
> pipe using a linux box and 2 ethernet interfaces representing the two
> endpoints of the T1.

Dave, does this add jitter as well?  I assume that since you're
queueing, it does to some extent.  Would it also be wise to inject
traffic on the simulated T1 connection by having other hosts
communicating as well?  For example I could have 1 linux system in
between 2 switches, on which were several other systems all
communicating with each other doing things like generating web
requests, copying large files, etc.

It seems this approach would add to the randomness of the connection
to some extent, and increase both the latency and jitter experienced
by the 2 systems we're really trying to test.

Thanks again!


-- 

Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Kevin D. Clark]

Ben Scott writes:

> On 3/7/06, Kevin D. Clark <[EMAIL PROTECTED]> wrote:
>> If all that you want to do is to introduce latency, I would suggest
>> using iptables "dstlimit" and "fuzzy" modules.
>
>   Will that really create a realistic reproduction of a higher latency
> link, though?  

It depends on what you mean by realistic.  Those things are basically
a very granular knob that you can turn to affect certain things.

> Assuming the throughput demands were minimal, 

I wasn't making any assumptions here.

> latency
> would remain low, wouldn't it?  And higher throughput demands would
> prolly result in TCP throttling or retransmissions or some such, which
> would be seen more as a bandwidth limit or bad line, not long
> transmission time, per se.

I wasn't assuming TCP or any sort of protocol that does congestion
control either.  In fact most of my experiences in this space are with
protocols that don't do congestion control.

Anyways, davej already offered a better solution.

Regards,

--kevin
-- 
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
   -- Tom Waits

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Paul Lussier]

Scott Mellott <[EMAIL PROTECTED]> writes:

> Try these on for size:
> http://linux-net.osdl.org/index.php/Netem#Emulating_wide_area_network_delays
> http://snad.ncsl.nist.gov/nistnet/

Dave Johnson <[EMAIL PROTECTED]> writes:

> Below script limits bandwidth in both directions when forwarding
> through two interfaces.  Note you'll need to setup the appropriate
> interfaces and routes.  Each side has it's own bandwidth and queue
> with a max size in bytes.  This is equivilant to a full-duplex T1
> pipe using a linux box and 2 ethernet interfaces representing the two
> endpoints of the T1.

Thank you both for some great information!
-- 

Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Dave Johnson]

Ben Scott writes:
> On 3/7/06, Kevin D. Clark <[EMAIL PROTECTED]> wrote:
> > If all that you want to do is to introduce latency, I would suggest
> > using iptables "dstlimit" and "fuzzy" modules.
> 
>   Will that really create a realistic reproduction of a higher latency
> link, though?  Assuming the throughput demands were minimal, latency
> would remain low, wouldn't it?  And higher throughput demands would
> prolly result in TCP throttling or retransmissions or some such, which
> would be seen more as a bandwidth limit or bad line, not long
> transmission time, per se.

dstlimit and fuzzy are both packet-per-sec limiters not bandwidth
limiters. It makes a big difference if all you packets aren't the same
size.

Note that as mentioned before, limiting bandwidth and introducing
latency and/or jitter are different things.

If you want to simulate a bandwidth limited link you need to both
limit bandwidth and queue packets.  If you simply drop and don't queue
then there is no possibility of latency.

Latency and jitter are side effects due to queuing prior to the
bandwidth limited hop.  Protocols such as TCP are designed to avoid
introducing latency when a slow link is in the path.

Anyway, onto the implementation.

Below script limits bandwidth in both directions when forwarding
through two interfaces.  Note you'll need to setup the appropriate
interfaces and routes.  Each side has it's own bandwidth and queue
with a max size in bytes.  This is equivilant to a full-duplex T1
pipe using a linux box and 2 ethernet interfaces representing the two
endpoints of the T1.

-- 
Dave


run this:



# the 2 interfaces you are forwarding through
SIDE_A=eth1
SIDE_B=eth2

# line rates (real and fake)
REALRATE=100mbit
FAKERATE=1500kbit

# max queue size on both ends (bytes)
QUEUESIZE=256kb

# SIDE B -> SIDE A
tc qdisc del dev $SIDE_A root
tc qdisc add dev $SIDE_A root handle 2: cbq bandwidth $REALRATE avpkt 1000
tc class add dev $SIDE_A parent 2: classid 2:1 cbq bandwidth $REALRATE \
  rate ${FAKERATE} allot 1514 maxburst 10 avpkt 1000 bounded prio 8
tc qdisc add dev $SIDE_A parent 2:1 handle 20: bfifo limit $QUEUESIZE
tc filter add dev $SIDE_A protocol ip parent 2: prio 100 u32 match ip \
  protocol 0 0 flowid 2:1

# SIDE A -> SIDE B
tc qdisc del dev $SIDE_B root
tc qdisc add dev $SIDE_B root handle 3: cbq bandwidth $REALRATE avpkt 1000
tc class add dev $SIDE_B parent 3: classid 3:1 cbq bandwidth $REALRATE \
  rate ${FAKERATE} allot 1514 maxburst 10 avpkt 1000 bounded prio 8
tc qdisc add dev $SIDE_B parent 3:1 handle 30: bfifo limit $QUEUESIZE
tc filter add dev $SIDE_B protocol ip parent 3: prio 100 u32 match ip \
  protocol 0 0 flowid 3:1

# show current usage
watch tc -s -d qdisc ls

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Ben Scott]

On 3/7/06, Kevin D. Clark <[EMAIL PROTECTED]> wrote:
> If all that you want to do is to introduce latency, I would suggest
> using iptables "dstlimit" and "fuzzy" modules.

  Will that really create a realistic reproduction of a higher latency
link, though?  Assuming the throughput demands were minimal, latency
would remain low, wouldn't it?  And higher throughput demands would
prolly result in TCP throttling or retransmissions or some such, which
would be seen more as a bandwidth limit or bad line, not long
transmission time, per se.

  I'm not sure it matters in practice, but it might.

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Ben Scott]

On 3/7/06, Paul Lussier <[EMAIL PROTECTED]> wrote:
> Does anyone here know of any way to *introduce* latency into a
> network?

  There are lots of fairly elegant solutions to this problem (using
things like iptables, traffic shaping, flux capacitors, etc.).  You
should probably use one of them.

  A non-elegant solution I used in the past was to force traffic
through a direct serial link between two Linux boxes.  If that isn't
bad enough, use a direct modem-to-modem link (no talk battery or dial
tone needed).

-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Kevin D. Clark]

Paul Lussier writes:

> I initially thought of connecting the GigE cards to a 10MB hub, but
> that's not really the same thing, and is still almost an order of
> magnitude faster than a T1.  I vaguely remember hearing about
> something that ran on linux that lets you tune the box to introduce
> variable amounts of latency into a connection, but can't remember what
> it is or where I saw it.

Do you want to introduce latency or jitter?  These are very different
things.

If all that you want to do is to introduce latency, I would suggest
using iptables "dstlimit" and "fuzzy" modules.

If you want to introduce jitter, then you'll need to introduce some
randomness to the network.  This might be as simple as running
bittorrent for some popular file...

Regards,

--kevin
-- 
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
   -- Tom Waits

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Neil Joseph Schelly]

On Tuesday 07 March 2006 04:08 pm, Paul Lussier wrote:
> Hi all,
>
> Does anyone here know of any way to *introduce* latency into a
> network?  We have a scenario where we've only ever tested our product
> over high-speed LAN connections (100MB and GigE).  However, we have
> some customers using it over T1 connections, so we need to start
> testing this scenario.

Perhaps you do this (on an isolated network) and generate a lot of other 
traffic to interfere?  A couple machines doing nothing but ping-flooding 
ought to be sufficient.  Certainly, if one of the machines flooding is also 
involved in the connection you are monitoring (either client or server).
-N
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Network testing and latency

[Tom Buskey]

Just saw an ad for http://simena.net/sys which sells a box to do this.On 3/7/06, Paul Lussier <
[EMAIL PROTECTED]> wrote:Hi all,Does anyone here know of any way to *introduce* latency into a
network?  We have a scenario where we've only ever tested our productover high-speed LAN connections (100MB and GigE).  However, we havesome customers using it over T1 connections, so we need to starttesting this scenario.
I initially thought of connecting the GigE cards to a 10MB hub, butthat's not really the same thing, and is still almost an order ofmagnitude faster than a T1.  I vaguely remember hearing aboutsomething that ran on linux that lets you tune the box to introduce
variable amounts of latency into a connection, but can't remember whatit is or where I saw it.Anyone here familiar with such a thing, or have any great ideas on howto achieve this?--Thanks,
Paul___gnhlug-discuss mailing listgnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss-- A strong conviction that something must be done is the parent of many bad measures.  - Daniel Webster

Network testing and latency

[Paul Lussier]

Hi all,

Does anyone here know of any way to *introduce* latency into a
network?  We have a scenario where we've only ever tested our product
over high-speed LAN connections (100MB and GigE).  However, we have
some customers using it over T1 connections, so we need to start
testing this scenario.

I initially thought of connecting the GigE cards to a 10MB hub, but
that's not really the same thing, and is still almost an order of
magnitude faster than a T1.  I vaguely remember hearing about
something that ran on linux that lets you tune the box to introduce
variable amounts of latency into a connection, but can't remember what
it is or where I saw it.

Anyone here familiar with such a thing, or have any great ideas on how
to achieve this?

-- 
Thanks,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Michael O'Donnell]

> No, [GPG] is not flawed, either, anymore than a wrench
> is "flawed" because it makes a lousy screwdriver.


Right.  Funny - this all reminds me of the time when
my little sister and I were presented with a pair
of walkie-talkies.  Our parents were initially pleased
to see how much fun we had using them, but we couldn't
understand why they were irritated about our wanting to
use them EVERYWHERE, even at the dinner table...

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Jerry Feldman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Derek,
On your key I get 
Signature made Mon 30 Dec 2002 01:19:00 PM EST using DSA key ID DFBEAD02
Good signature from "Derek D. Martin <[EMAIL PROTECTED]>"
WARNING: This key is not certified with a trusted signature!
 There is no indication that the signature belongs to the owner.

We signed eachothers keys last year. Did you change your key since then.
- -- 
- --
Gerald Feldman <[EMAIL PROTECTED]>
Boston Computer Solutions and Consulting
ICQ#156300 PGP Key ID:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 12/25/2001

iD8DBQE+EPsu+wA+1cUGHqkRAuYcAJ41RwWwT5Ew27TwoKuAFxaY3KKJugCfRNEs
gHXSF4wyGWB6w1HdEKVYGqM=
=WTcP
-END PGP SIGNATURE-

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[Travis Roy]

> On Mon, 30 Dec 2002, at 8:10am, [EMAIL PROTECTED] wrote:
> [commentary about non-repudiation not being possible on the Internet]
>> This was EXACTLY my point as to why GPG/PGP for signing email is
>> currently
>> flawed the way it works now.
>
>   No, it is not flawed, either, anymore than a wrench is "flawed" because
> it
> makes a lousy screwdriver.  It is solving a different problem.  I repeat:
> PGP/GPG allow two parties who trust each other to exchange messages over
> an
> untrusted medium.  Nothing more, and nothing less.  If you assume it
> provides something else, the flaw is with your understanding, not with
> PGP/GPG.  :-)

Right, I ment using it for trying to prove you're not sending spam, or to
use it by just signing all your emails blindly and thinking that everybody
that recives it is going to trust it.
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[bscott]

On Mon, 30 Dec 2002, at 8:10am, [EMAIL PROTECTED] wrote:
[commentary about non-repudiation not being possible on the Internet]
> This was EXACTLY my point as to why GPG/PGP for signing email is currently
> flawed the way it works now.

  No, it is not flawed, either, anymore than a wrench is "flawed" because it
makes a lousy screwdriver.  It is solving a different problem.  I repeat:
PGP/GPG allow two parties who trust each other to exchange messages over an
untrusted medium.  Nothing more, and nothing less.  If you assume it
provides something else, the flaw is with your understanding, not with
PGP/GPG.  :-)

  On today's Internet, achieving non-repudiation is an impossibility.  As
long an unsigned message is acceptable and routine, people can send a
message they can repudiate.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[Travis Roy]

This was EXACTLY my point as to why GPG/PGP for signing email is
currently flawed the way it works now.

>   Case in point: This discussion originated as a discussion 
> about using digital signatures to counter spam.  Since 
> digital signatures, on today's Internet, are relatively 
> uncommon, they do not provide non-repudiation.  
> Thus, digital signatures cannot be used to prove one did not 
> send a given spam.
> 
>   Now, I am sure someone will say, "If you sign all your 
> messages, then the unsigned spam will be suspect, because it 
> lacks your digital signature."
> 
>   That again misses the most fundamental aspect of security: 
> Security is entirely about trust.  Someone sending 
> illegitimate mail is, almost by definition, not to be 
> trusted.  Thus, if you are suspected of sending an 
> illegitimate message, the fact that you nominally sign all 
> your messages does not impart trust.  Indeed, one who 
> regularly traffics in illegitimate messages would be rather 
> more likely to sign all their legitimate mail.  
> Meanwhile, if you can, by other means, prove you are 
> trustworthy, the digital signature becomes superfluous.  We 
> already know you are trustworthy;  
> thus, we don't need a digital signature to know you did not 
> send the illegitimate message.


___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sat, 28 Dec 2002, at 11:06pm, [EMAIL PROTECTED] wrote:
> Like everything else pertaining to information assurance, it's a matter of
> risk management.

  That is exactly my point.  :-)

  The more I deal with the world, the more I think that the word "security"  
is inherently misleading.  I agree with those who say that "trust" is the
better term.  Too many people think security -- trust -- can be achieved
with tools.  Everyone knows a tool is only as good as the person using it.  
A tool itself cannot be trusted.  Only a person can be trusted.

  The crypto-nuts like to push the concept of "anonymous trust".  The idea
is that, with a proper PKI, two parties can exchange messages, and trust
them, even if they do not know anything about each other.  I find that
concept absurd.

  A digital signature only tells you that a message came from a certain
end-point.  It does not tell you anything about the person or people behind
that end-point.  Liars and idiots can sign messages, too.  Criminals can
sign messages.  If I don't know anything about you, a "secure" message
exchange with you is of limited use.

  My point is that PGP solves one problem:  It allows two parties who
already trust each other to exchange messages over an untrusted medium.  It
cannot do anything to help two parties who do not trust each other.

  The is another point worth making here: Signing all your messages
implicitly dilutes the value of the key you use to sign them.  As
[EMAIL PROTECTED] points out, draconian security measures and a policy of
always signing your messages do not mix.  A key you use all the time is, by
necessity, going to be more exposed.  Thus, it makes sense to have more than
one key.  The one you use for every-day correspondence might be stored on
online, stored in multiple locations, use an easier passphrase, and/or use a
key-agent to avoid having to enter the passphrase repeatedly in a single
session.  The key you use to sign an electronic contract, on the other hand,
might be stored on a disk in a safe, and only be used on a system not
connected to any network.  The latter policy, incidentally, is what the US
military generally uses when it comes to cryptography.  They know that
cryptography is only as good as the procedures surrounding it.  Of course,
they also face substantially higher risks than the average computer user.  
:-)

  (I realize that Derek and others on this list already realize this.  
However, others likely do not, and even the best of us (and me, too) could
stand to be reminded of this now and again.)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |




___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sun, 29 Dec 2002, at 10:24pm, [EMAIL PROTECTED] wrote:
>> That is rather missing the point.  The reason non-repudiation is desired
>> is that it means one cannot say, "I never sent that."
> 
> No, that's only one reason.  The other reason is to say, "we can prove
> that you sent this."

  No, that's authentication.

  Non-repudiation, by definition, means one cannot repudiate any given
message.  Repudiation, by definition, is the act of denying you sent a
message.  If signing is voluntary, you can always assert that you simply did
not sign a given message.  Thus, voluntary signing does not provide
non-repudiation.

> In such a case, you definitely want them to be digitally signed, and
> reject anything that isn't.

  If anything which is not signed is rejected, then signing is not
voluntary, is it?

  Case in point: This discussion originated as a discussion about using
digital signatures to counter spam.  Since digital signatures, on today's
Internet, are relatively uncommon, they do not provide non-repudiation.  
Thus, digital signatures cannot be used to prove one did not send a given
spam.

  Now, I am sure someone will say, "If you sign all your messages, then the
unsigned spam will be suspect, because it lacks your digital signature."

  That again misses the most fundamental aspect of security: Security is
entirely about trust.  Someone sending illegitimate mail is, almost by
definition, not to be trusted.  Thus, if you are suspected of sending an
illegitimate message, the fact that you nominally sign all your messages
does not impart trust.  Indeed, one who regularly traffics in illegitimate
messages would be rather more likely to sign all their legitimate mail.  
Meanwhile, if you can, by other means, prove you are trustworthy, the
digital signature becomes superfluous.  We already know you are trustworthy;  
thus, we don't need a digital signature to know you did not send the
illegitimate message.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sat, 28 Dec 2002, at 9:56pm, [EMAIL PROTECTED] wrote:
> They do provide one-way non-repudiation... in the case the mail was
> signed.

  That is rather missing the point.  The reason non-repudiation is desired
is that it means one cannot say, "I never sent that."  Discretionary signing
means one has the option of saying that.  Thus, it defeats the purpose.  
Rather like a parachute, non-repudiation is only trustworthy if it always
works.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[Travis Roy]

> You should probably ask what is meant by that before you rush 
> to such conclusions...  In two messages in this thread you 
> seem in quite a hurry to bash PGP...  The key servers are not 
> a security risk to PGP users or "broken" in any serious sense 
> (that I'm aware of).  However most of them do not support 
> some of the newer features (like subkey
> expiry) of the OpenPGP standards.  This is all mike meant.

I understand this, but just as people bitch about how some sites are IE
only or such and such a server doesn't correctly follow RFCwhatever it
amazes me that these same people (not you specifically) don't seem to
care when other people that are big on open source or other "good"
projects don't follow their own rules. There's no real reason for all
the public key servers to implement all the fetures of the current
standard for OpenPGP except that the admin is either stubborn and
doesn't want to change, lazy and doesn't want to upgrade, or think that
everything is fine and that they don't need to upgrade, but that last
one of course will break some functionallity. In any of those cases I
wouldn't want to use their service.

I say that being one of the admins in the lazy category when it comes to
my own server some times, but I also don't expect many people to use my
server for such a critical application as signing emails. But for the
few things in the past that I used to run that were accessed by a good
number of people I made sure that all the programs that were used were
up to date and had all the current features available to my users. 
 
> Speculative, subjective...  If you have a better way to do 
> what PGP does, then by all means...

Typical open source response.. If you don't like it, do it yourself..
That's why there's lots of varients of the same program that do the same
thing, just that one might have a feature that another lacks. What's
wrong with saying that's something is flawed or needs this or that and
then implementing it or fixing the current application out there. Sure,
it's nice to have choice and all, and if somebody wants to start another
project that does the same thing that's fine.. But there are probably
ways to fix the current system to be better without restarting a project
from scratch.
 
> Well that's just dumb, but dumb people are everywhere...  You 
> can't blame PGP for that.

That is true.

Let me finish that I'm not anti-PGP/GPG or anti-open source. I'm
pro-whateverisbestforthejob. That's why I still use windows on my
desktop because for me it's the best suited for what I do. My server is
linux, my shared drives are on a linux server. My neighbor's sun drive
array is hooked up to a sun box running solaris and veritas because
that's the best suited for the job. I used GPG and PGPFreeware in the
past and I was never convinced that it could actually prove that I sent
the email to anybody I actually sent email to, and to the few that could
actually verify it the emails I sent them were stuff like this list mail
or just a "hey whare are you doing" type of email. I still have it, and
I do use it sometimes but only when I need it because the email is
something important and that I know the person getting the email can
check it..

> 
> - -- 
> Derek D. Martin
> http://www.pizzashack.org/
> GPG Key ID: 0xDFBEAD02
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE+DnYMHEnASN++rQIRAgyaAJ9zg4RRPv82O6x/FMTQN0CqjZ8DZwCfU3lE
> TgylYqBzwLI53lS/2AYisFg=
> =gO7x
> -END PGP SIGNATURE- 
> ___
> gnhlug-discuss mailing list
> [EMAIL PROTECTED] 
> http://mail.gnhlug.org/mailman/listinfo/gnhlug> -discuss
> 

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[Travis Roy]

> I'm guessing that you don't really understand how OpenPGP 
> works; the keyservers are *NOT* trusted, so problems with the 
> keyservers do not affect the operation of GPG or PGP, except 
> that it may make it harder to obtain a copy of someone's key.

I understand that the keyservers are not trusted, but as somebody else
pointed out earlier, I can make a bogus email address and user on my
server with your email address and screw with the headers all I want, I
can also make a PGP/GPG key with your email address and post that to the
public key servers then send out all the signed mail I want as you. 

How do you prove to people that are now getting signed mail from me (but
PGP/GPG signed as you) that it's not you, and if they do believe you
then why wouldn't they if the e-mail wasn't signed at all?

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Mark Komarinski]

On Sat, Dec 28, 2002 at 09:59:46PM -0500, Travis Roy wrote:
> > My public key is available from my web site as well, if only 
> > Outlook would show all the headers (or does it now?).  Hence 
> > the reason why I asked if I should publish it on the 
> > keyservers or leave it on my web site.
> 
> Outlook has always had access to the entire headers, even from the
> earliest versions of outlook express.. View, Options, look, all the
> headers.. TA-DA
 
Ah.  I used outlook for ~6 mos and never got that working.

> 
> 
> I know this is a linux list and all, but MS bashing is lame when it's
> not even stuff that's true.

I stand corrected.

-Mark



msg01976/pgp0.pgp
Description: PGP signature

RE: GPG testing...

[Travis Roy]

> My public key is available from my web site as well, if only 
> Outlook would show all the headers (or does it now?).  Hence 
> the reason why I asked if I should publish it on the 
> keyservers or leave it on my web site.

Outlook has always had access to the entire headers, even from the
earliest versions of outlook express.. View, Options, look, all the
headers.. TA-DA


Return-Path: <[EMAIL PROTECTED]>
Received: from shaft (enry.ne.client2.attbi.com [24.128.211.189])
by scootz.net (8.11.6/8.11.6) with ESMTP id gBT1qrB17201
for <[EMAIL PROTECTED]>; Sat, 28 Dec 2002 20:52:53 -0500
Received: from mkomarinski by shaft with local (Exim 3.35 #1 (Debian))
id 18SSd9-00019J-00; Sat, 28 Dec 2002 20:52:43 -0500
Date: Sat, 28 Dec 2002 20:52:43 -0500
From: Mark Komarinski <[EMAIL PROTECTED]>
To: Travis Roy <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: GPG testing...
Message-ID: <[EMAIL PROTECTED]>
Reply-To: Mark Komarinski <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<002f01c2aeb6$938b8370$301216cf@winbox>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="ReaqsoxgOBHFXBhH"
Content-Disposition: inline
In-Reply-To: <002f01c2aeb6$938b8370$301216cf@winbox>
User-Agent: Mutt/1.4i
X-PGP-Key: http://www.wayga.org/~mkomarinski/mkomarinski.asc
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level: 


I know this is a linux list and all, but MS bashing is lame when it's
not even stuff that's true.

 

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Roger H. Goun]

On Sat, Dec 28, 2002 at 03:32:25PM -0500, mike ledoux
<[EMAIL PROTECTED]> wrote:
> Your key wasn't on any of the keyservers, but I've got mutt
> configured to grab keys from certain URLs in the headers so getting
> your key wasn't a problem for me.

Neat trick. How do you do that?

-- Roger

-- 
Roger H. Goun  Brentwood Country Animal Hospital, P.C.
Chief Kennel Officer   Exeter, New Hampshire, USA



msg01974/pgp0.pgp
Description: PGP signature

Re: GPG testing...

[Mark Komarinski]

On Sat, Dec 28, 2002 at 04:17:49PM -0500, Travis Roy wrote:
> > and Outlook users will not be able 
> > to read the message at all.  
> 
> I use Outlook (the one with OfficeXP) and it came up fine, just had an
> attachment that some people might be scared of
 
Bah. ;)

> > My recommendation is to publish your key to 
> > 'keyserver.kjsl.com', which is currently the least broken keyserver.
> 
> Oh goodie, the "least broken" keyserver, that of course means that it
> still has issues and is probably broken in some way. This makes me want
> to use GPG or PGP every day and trust it :)
 
My public key is available from my web site as well, if only Outlook
would show all the headers (or does it now?).  Hence the reason why
I asked if I should publish it on the keyservers or leave it on
my web site.

> Seriously, how can you trust anything like this.. There's gotta be a
> better way. Most of the ways I've seen people use GPG/PGP is stupid
> anyway. Some people sign emails that they know 95% of the people that
> recive them will either not bother to confirm the GPG/PGP sig or don't
> know how.. Of they use it to encrypt files and put it on a disk only to
> put the pass phrase on the disk or email it to people over an unencryped
> channel (this happens to me all the time at work).

There seems to be a lot of confusion over how to properly sign a GPG/PGP
e-mail.  Too bad the MUAs (even the open source ones) can't get together
and standardize.  mutt will verify the signature, but only if I have
the key (which I guess I can get) and if it's signed in PGP/MIME format.
Those that don't use MIME just shows up to me as a regular e-mail and the
signature is not checked.  Knowing how touchy M*A people about their
products, this is probably intentional.

-Mark



msg01973/pgp0.pgp
Description: PGP signature

RE: GPG testing...

[Travis Roy]

> and Outlook users will not be able 
> to read the message at all.  

I use Outlook (the one with OfficeXP) and it came up fine, just had an
attachment that some people might be scared of


> My recommendation is to publish your key to 
> 'keyserver.kjsl.com', which is currently the least broken keyserver.

Oh goodie, the "least broken" keyserver, that of course means that it
still has issues and is probably broken in some way. This makes me want
to use GPG or PGP every day and trust it :)

Seriously, how can you trust anything like this.. There's gotta be a
better way. Most of the ways I've seen people use GPG/PGP is stupid
anyway. Some people sign emails that they know 95% of the people that
recive them will either not bother to confirm the GPG/PGP sig or don't
know how.. Of they use it to encrypt files and put it on a disk only to
put the pass phrase on the disk or email it to people over an unencryped
channel (this happens to me all the time at work).

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

RE: GPG testing...

[Travis Roy]

> Isn't one of the points of GPG to validate that the person 
> you're talking to is really who they say they are?  GPG 
> allows me to do that, by signing my e-mails.  If it's not 
> signed, then it's not from me.

I used pgp for a while and I actually found it more of a hassle
explaining to people what the hell that shit was as the bottom of my
email or what this stupid attachment was then actually using pgp.. It
works good for geeks but anybody else just gets confused and thinks
you're sending them a virus or trying to h4xx0r their computer.

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sat, 28 Dec 2002, at 2:08pm, [EMAIL PROTECTED] wrote:
>>   It validates that the sender had access to your private key.  Presumably,
>> only you have access to your key, but even that is far from a given in
>> anonymous communications.
> 
> They'd also need your pass phrase. They'd need your private key and your
> passphrase to forge a signature.

  Your passphrase is used to protect your key.  You encrypt the key with
your passphrase and store the ciphered key in your keychain.  The ciphertext
itself is not your key.  Once you enter your passphrase, the ciphertext is
decrypted to produce your key.  If someone has access to that key, they can
sign messages with it.

  This isn't just a semantic argument.  Yes, the most obvious way to gain
access to a key is to obtain both the keychain and the passphrase.  
However, it is important to not lose sight of that fact that the ciphertext
itself is not the key, and that the ciphertext must be decrypted before the
key can be used.  That point *has* been attacked before.  For example, not
every system handles data residue properly.  This is generally not a problem
on Linux, which always zeros memory before giving a new page to a process,
and which can be told to never swap pages out to disk.  But what if someone
is using a system that doesn't handle that properly?  An attacker might find
a copy of your key in memory or in the swap file somewhere.  As you say, if
this is your home computer, that indicates a bigger problem.  But what if
you're on a corporate system?  Sure, you can make the argument that you
shouldn't use such a system to sign messages, but that's not always
practical, either.

> Something more like the way server certificates are handed out is better,
> IMHO.  At least some presumabely competent authority checks that you are
> who you claim to be, and then issues the certificate.

  Hah.  VeriSign is only interested in verifying that they have your money.  
Witness the certificate issued to the guy claiming to be Microsoft a year or
two ago.

> If someone sticks a key on a keyserver claiming to be you, there isn't
> anything you can do about it.

  A public key that has not been signed by trusted parties should not be
trusted.

  The central CA scenario is just a degenerate case of the general
keysigning technique.  The idea is, you have other trusted parties sign your
public key.  They thus assert your public key is legitimate.  In the central
CA scenario, you have a single authority everyone trusts.  That can be good
(airplane rule) or it can be bad (single point of attack).  In the
web-of-trust scenario, peers sign keys of their peers, who sign keys of
their peers, and so on.  In theory, a large web of trust provides
decentralized authentication that you can still put faith in.

  IMO, right now, for general pubic use, we really do not have any kind of
trustworthy PKI.  The peer trust web that PGP and/or GPG desire is still far
too immature for everyday use, and the de facto PKI that has formed around
SSL is run by corporations with a dubious record.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Jason Stephenson]

[EMAIL PROTECTED] wrote:

On Sat, 28 Dec 2002, at 1:45pm, [EMAIL PROTECTED] wrote:


Isn't one of the points of GPG to validate that the person you're talking
to is really who they say they are?



  It validates that the sender had access to your private key.  Presumably,
only you have access to your key, but even that is far from a given in
anonymous communications.


They'd also need your pass phrase. They'd need your private key and your 
passphrase to forge a signature. In most cases, that mean physical 
access to your hardware and the area where you keep your passphrase 
written down (if you do such a thing). IMHO, you've got more problems in 
that case than someone simply forging signed emails.




GPG allows me to do that, by signing my e-mails.  If it's not signed, then
it's not from me.



  Well, you can assert that, but GPG has nothing to do with it.  An unsigned
message has no authentication information, one way or the other.  There is
certainly nothing keeping you from sending an unsigned message.  Of course,
people you know might beleive you when you say that if it was not signed, it
was not from you, but presumably, if people are willing to trust your word
on that, they would also trust your word if you just said you did not send
the mail in question in the first place.




I agree with Mr. Scott on the last part. Always signing your mails, and 
having a mailer that does autosign is great, *may* give you a level of 
comfort over not signing mails. However, you have absolutely no way to 
prove that you didn't send the non signed message that says it came from 
you.

Furthermore, there's nothing to stop a malicious person from publishing 
a key and say its for your email address and use that key to sign 
messages. Now, you might have even bigger problems depending upon what 
they want to do to you.

OpenPGP is all right as far as it goes, but there is not built-in 
authority. You have to trust your key sources and check with people you 
know before trusting any keys.

Something more like the way server certificates are handed out is 
better, IMHO. At least some presumabely competent authority checks that 
you are who you claim to be, and then issues the certificate. There's an 
audit trail and if someone tries to spoof you, there's a good chance 
you'll catch 'em. If someone sticks a key on a keyserver claiming to be 
you, there isn't anything you can do about it.

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sat, 28 Dec 2002, at 1:45pm, [EMAIL PROTECTED] wrote:
> Isn't one of the points of GPG to validate that the person you're talking
> to is really who they say they are?

  It validates that the sender had access to your private key.  Presumably,
only you have access to your key, but even that is far from a given in
anonymous communications.

> GPG allows me to do that, by signing my e-mails.  If it's not signed, then
> it's not from me.

  Well, you can assert that, but GPG has nothing to do with it.  An unsigned
message has no authentication information, one way or the other.  There is
certainly nothing keeping you from sending an unsigned message.  Of course,
people you know might beleive you when you say that if it was not signed, it
was not from you, but presumably, if people are willing to trust your word
on that, they would also trust your word if you just said you did not send
the mail in question in the first place.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[bscott]

On Sat, 28 Dec 2002, at 1:37pm, [EMAIL PROTECTED] wrote:
>> So some fsckwad is using my good name to send spam.  Either that,
>> or there's a new spam going around that just says 'fuck you'.
> 
> Fascinating.  Why would anybody do such a thing to you? 

  Spammers often spoof the 'From' header to be someone else's email address,
to make the spam hard to trace.  They have to choose *someone's* email
address when they do that.  They often choose one from the same pool of
addresses they harvest from.  So, someone unlucky soul gets lots of hate
mail from upset lusers who just hit the 'Reply' button.  I've been in that
position myself, before.  It's great fun.  

>> So, time to start signing with GPG so at least I know when I sent
>> something, and the rest of you do, too.  I've got mutt set up on
> 
> What would have been different if you'd used GPG?

  Very little, IMO.  Even if said lusers know what GPG is, they have no way
of knowing the forged sender uses it.  And people the victim already knows
generally will realize from context that the the sender did not send the
message in question.  It doesn't even prove the sender did not send the
spam, since voluntary crypto-systems like GPG don't provide non-repudiation.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or  |
| organization.  All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Mark Komarinski]

On Sat, Dec 28, 2002 at 01:37:22PM -0500, Michael O'Donnell wrote:
> 
> 
> > So some fsckwad is using my good name to send spam.  Either that,
> > or there's a new spam going around that just says 'fuck you'.
> 
> Fascinating.  Why would anybody do such a thing to you?  Do you
> have enemies?  Where can one see an example of the forgery?
 
No, but this e-mail is floating about all sorts of places.  E-mail lists,
LDP docs, someone's inbox.  Not much of a stretch for someone to just use
real e-mail addresses instead of fake-looking e-mail addresses.  I've only
received a few indications that this is happening, fortunately.  Didn't
sircam spread using similar methods?

> > So, time to start signing with GPG so at least I know when I sent
> > something, and the rest of you do, too.  I've got mutt set up on
> 
> What would have been different if you'd used GPG?

Isn't one of the points of GPG to validate that the person you're talking
to is really who they say they are?  GPG allows me to do that, by signing
my e-mails.  If it's not signed, then it's not from me.

-Mark



msg01965/pgp0.pgp
Description: PGP signature

Re: GPG testing...

[John Abreau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Mark Komarinski <[EMAIL PROTECTED]> writes:

> 1)  Can you read this?

Yes, I can read your message, but exmh was unable to auto-fetch your key; 
I had to do that by hand and then import it into my keyring.

> 3)  To publish keys or not?  IIRC, I sent a key to pgp a while ago and

Personally, I lean toward publishing the public key on the keyservers 
unless there's a reason not to. For instance, if I were using a pgp key 
to authenticate my domain name registrations, I wouldn't publish that 
key; but I would publish a key I use for day-to-day email. 

> 5)  When I get my key signed by someone else, I have to re-export
> my key, or rather, have anyone that already has my key re-fetch it?

Yes, I'm not aware of any auto-refresh function in gpg; people who have 
a copy of your public key would have to re-fetch it to pick up any 
new signatures you may gather. 


- --
John Abreau / Executive Director, Boston Linux & Unix
Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iQCVAwUBPg3welV9A5rVx7XZAQKFcQP/VCut9JoX0nbSd2kUHTNs9700E0i8lXYD
jsyE2AU8tbIYpeuossu2qpszVypvWKZ122Te8pKjNpkLF58kfFVyKgejXmASQZ55
tktyiOP1e+UQnbtqsUfIrxKi66QWFpEFop1Vw3TInNhsXinY5/LysUuN84E3COH4
AzR6LPXHgWs=
=jK+R
-END PGP SIGNATURE-

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: GPG testing...

[Michael O'Donnell]

> So some fsckwad is using my good name to send spam.  Either that,
> or there's a new spam going around that just says 'fuck you'.

Fascinating.  Why would anybody do such a thing to you?  Do you
have enemies?  Where can one see an example of the forgery?

> So, time to start signing with GPG so at least I know when I sent
> something, and the rest of you do, too.  I've got mutt set up on

What would have been different if you'd used GPG?

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

GPG testing...

[Mark Komarinski]

So some fsckwad is using my good name to send spam.  Either that, or
there's a new spam going around that just says 'fuck you'.

So, time to start signing with GPG so at least I know when I sent something,
and the rest of you do, too.  I've got mutt set up on my home machine and
have GPG set up with it, along with a key I've been tinkering around
with for a while.  But after getting all the documentation set for that,
I have a bunch of remaining questions that maybe you mutt/gpg users
can help out with:

1)  Can you read this?
2)  If you look at my public key, you'll see that it has three e-mail
addresses associated with it.  Is that the way to do it, or should I
have three separate keys?  On the one hand, this verifies that I am
who I say I am no matter what e-mail address I use.  On the other,
it triples the possibility of a key being compromised and increases
the maintenance (since I have to make sure I have the same private/public
key on three systems).
3)  To publish keys or not?  IIRC, I sent a key to pgp a while ago and
it's still there, but that was maybe 5 years ago.  I don't have any
of that key information anymore, let along a revocation key.  I'm a bit
smarter now, and have the revocation key for this printed and in a 
safe.
4)  Can mutt automagically get public keys when I don't have someone's
key, or is that a manual process?
5)  When I get my key signed by someone else, I have to re-export
my key, or rather, have anyone that already has my key re-fetch it?
6)  Anything I've missed?

-Mark



msg01963/pgp0.pgp
Description: PGP signature

TESTING - please ignore

[Michael O'Donnell]

> "You'll pay to know what you really think."
> -- J.R. "Bob" Dobbs

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Testing gnhlug subscription

[Derek D. Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At some point hitherto, Jerry Feldman hath spake thusly:
> Don't we routinely do that Derek :-).

:)

Of course as Mr. Brodeur pointed out, it's hard for one to ignore the
message when one is being told to do so in the message...

Oh well.  ;-)

> Actually, check your list options to see if your account is set to nomail. 

I dunno if that was it or not, but it's fixed now, whatever it was.

Oh, and thanks to everyone who verified my signature!

- -- 
Derek Martin   [EMAIL PROTECTED]
- -
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VC2TdjdlQoHP510RAiZsAKCD+zzVBlBCmX9LKZno1Wx9/JxuLwCguRSF
pv5vTGC06YQwtnKf0bhgmW4=
=Jqg7
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Re: Testing gnhlug subscription

[Jerry Feldman]

Don't we routinely do that Derek :-).
Actually, check your list options to see if your account is set to nomail. 
On 9 Aug 2002 at 16:12, Derek D. Martin wrote:
> Please ignore...

-- 
Jerry Feldman <[EMAIL PROTECTED]>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss

Testing gnhlug subscription

[Derek D. Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please ignore...

- -- 
Derek Martin   [EMAIL PROTECTED]
- -
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VCIvdjdlQoHP510RAmFYAJ0UyiM0dJ9vI3KkSAx+YQsoHe1DuACgppqR
Fi4pte7Izl2Z+wvhzGY7IiA=
=Gwm/
-END PGP SIGNATURE-
___
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss