incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: firewall support for ec2 instances
Date Thu, 07 Jul 2011 14:31:52 GMT
On 07/07/11 17:21, Sang-Min Park wrote:
> Here's answer from Mitch.
>
> ---------- Forwarded message ----------
> From: Mitch Garnaat<mitch.garnaat@eucalyptus.com>
> Date: Thu, Jul 7, 2011 at 7:19 AM
> Subject: Re: AuthorizeSecurityGroupIngress
> To: Sang-Min Park<sang-min.park@eucalyptus.com>
>
>
> Hi Sang-Min -
>
> It is true that you can specify both a group and a cidr on the
> AuthorizeSecurityGroupIngress request for EC2.  However, EC2 silently
> ignores the cidr block and simply authorizes the group.  To prove this, if
> you do a DescribeGroups request after the authorize request, you will see no
> mention of the cidr block in the group description.
>

Ok, well you made me doubt it enough to actually go try it out, *again*. 
AuthorizeSecurityGroupIngress, using my 'manage_security_groups_ingress' 
method in appoxy aws gem DOES work for a mix of IP address, and groups. 
To make sure everything was in order I actually logged in to 
aws.amazon.com/console to double check the security groups rules there. 
Perhaps the behaviour that Mitch is describing was true in older 
versions of the API. I don't know what else to say, besides I just did 
this, and it works,


marios



> On Thu, Jul 7, 2011 at 7:01 AM, Sang-Min Park
> <sang-min.park@eucalyptus.com>wrote:
>
>> It uses soap interface. Euca2ools (boto underneath) uses query interface
>> and quite popular.
>> I'll ask our tool master (Mitch who manages boto) if he's aware of this.
>>
>> -- SM
>>
>>
>> On Thu, Jul 7, 2011 at 6:52 AM, marios@redhat.com<mandreou@redhat.com>wrote:
>>
>>> On 07/07/11 16:48, Sang-Min Park wrote:
>>>
>>>> I tried 'ec2-authorize' in the latest ec2-api-tools, and it doesn't allow
>>>> the mix.
>>>> Here's the output:
>>>>       Specify either source groups or source CIDRs, not both. (-h for
>>>> usage)
>>>>
>>>> I could create a rule with multiple groups or a rule with multiple ip
>>>> range.
>>>> But I couldn't give -s [cidr] -o [group] option together.
>>>>
>>>> -- SM
>>>>
>>>
>>> thanks for trying that - well, that's very interesting indeed. I wonder
>>> why AWS allows this via the REST API but not via their own command line
>>> tools? This might be one for investigation for when I next get some idle
>>> time (e.g. what calls is the ec2-api-tools making? which interface is it
>>> using etc)
>>>
>>> marios
>>>
>>>
>>>
>>>>
>>>> On Thu, Jul 7, 2011 at 5:37 AM, marios@redhat.com<mandreou@**redhat.com<mandreou@redhat.com>
>>>>> wrote:
>>>>
>>>>   On 07/07/11 15:02, Sang-Min Park wrote:
>>>>>
>>>>>   I haven't tried this mix and it was purely speculation from the API.
>>>>>>
>>>>>>
>>>>> ok
>>>>>
>>>>>
>>>>>   Here's the specific line in the link:
>>>>>
>>>>>>
>>>>>> "Name of the source security group. Cannot be used when specifying
a
>>>>>> CIDR
>>>>>> IP
>>>>>> address."
>>>>>> "CIDR range. Cannot be used when specifying a source security group."
>>>>>>
>>>>>>
>>>>>>   yeah, ok i see now. This was also a source of confusion/frustration
>>>>> for me
>>>>> when i was writing the firewalls code. In the end I think this can just
>>>>> be
>>>>> taken literally - e.g. for 'name of the source group' : "you cannot use
>>>>> this
>>>>> parameter when specifying an IP address, since this refers to groups,
>>>>> not
>>>>> addresses".
>>>>>
>>>>>
>>>>>   Also, ec2-authorize (
>>>>>
>>>>>> http://docs.amazonwebservices.****com/AWSEC2/2011-01-01/**
>>>>>> CommandLineReference/index.****html?ApiReference-cmd-**
>>>>>> AuthorizeSecurityGroupIngress.****html<http://docs.**
>>>>>> amazonwebservices.com/AWSEC2/**2011-01-01/**
>>>>>> CommandLineReference/index.**html?ApiReference-cmd-**
>>>>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/CommandLineReference/index.html?ApiReference-cmd-AuthorizeSecurityGroupIngress.html>
>>>>>>>
>>>>>>
>>>>>> )
>>>>>> doesn't allow the mix.
>>>>>>
>>>>>>
>>>>>>   OK, this is interesting. First off, did you try this? What was
the
>>>>> result?
>>>>> This line:
>>>>>
>>>>> "
>>>>> For EC2 security groups and ingress rules: This command either gives
one
>>>>> or
>>>>> more CIDR IP address ranges permission to access a security group in
>>>>> your
>>>>> account, or it gives one or more security groups (
>>>>> "
>>>>>
>>>>> seems to suggest what you're saying. However, this line:
>>>>>
>>>>> "
>>>>> Each rule consists of the protocol (e.g., TCP), plus either a CIDR
>>>>> range,
>>>>> or a source group (for ingress rules) or destination group (for egress
>>>>> rules).
>>>>> "
>>>>>
>>>>> Note the use of 'a CIDR range' or 'a source group' - the plural is
>>>>> dropped;
>>>>> also, all the examples on that page seem to specify just a single
>>>>> source,
>>>>> either an address, or a group. *This* might be the reason that you can
>>>>> specify address OR ip, since you only specify one. Of course, this is
>>>>> all
>>>>> speculation, why don't you try this out and let us know the answer?
>>>>>
>>>>>
>>>>>   If you made the call without an error, it's maybe wrong documentation.
>>>>>
>>>>>>
>>>>>>
>>>>> Of course I made the call - many, many times. I would never submit
>>>>> something for inclusion without it being tested first, not least because
>>>>> this code was a contribution to a another project (the appoxy aws gem).
>>>>> The
>>>>> question however should be turned on its head - did you make the call,
>>>>> and
>>>>> did it cause the error that you are reporting here?
>>>>>
>>>>> marios
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   -- SM
>>>>>>
>>>>>> On Wed, Jul 6, 2011 at 11:23 PM, marios@redhat.com<mandreou@**r**
>>>>>> edhat.com<http://redhat.com><mandreou@redhat.com>
>>>>>>
>>>>>>   wrote:
>>>>>>>
>>>>>>
>>>>>>   On 07/07/11 00:16, Sang-Min Park wrote:
>>>>>>
>>>>>>>
>>>>>>>   Marios,
>>>>>>>
>>>>>>>>
>>>>>>>> I looked at your aws patch (manage_security_group_******ingress)
and
>>>>>>>> wonder
>>>>>>>> if you
>>>>>>>> considered the limitation that either a cidr IP range or
user-group
>>>>>>>> pair
>>>>>>>> can
>>>>>>>> be given, not both.
>>>>>>>>
>>>>>>>>
>>>>>>>>   why? Or rather, how have you arrived at this conclusion?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In other words,
>>>>>>>
>>>>>>>
>>>>>>>   source_ip_ranges.each_index do |i|
>>>>>>>>          call_params.merge!({"******IpPermissions.1.IpRanges.#{i+***
>>>>>>>> **
>>>>>>>> *1}.CidrIp"
>>>>>>>> =>
>>>>>>>> source_ip_ranges[i].to_s})
>>>>>>>> end
>>>>>>>> source_groups.each_index do |i|
>>>>>>>>        call_params.merge!({"******IpPermissions.1.Groups.#{i+1}.****
>>>>>>>> **GroupName"
>>>>>>>> =>
>>>>>>>> source_groups[i]['group_name']******.to_s,
>>>>>>>>                              "IpPermissions.1.Groups.#{i+1}****
>>>>>>>> **.UserId"=>
>>>>>>>> source_groups[i]['owner'].to_******s.gsub(/-/,'')})
>>>>>>>>   end
>>>>>>>>
>>>>>>>> If a user gives both source ip range and groups to the method,
it may
>>>>>>>> end
>>>>>>>> up
>>>>>>>> a request like this:
>>>>>>>>
>>>>>>>> &IpPermissions.1.IpProtocol=******tcp
>>>>>>>> &IpPermissions.1.FromPort=80
>>>>>>>> &IpPermissions.1.ToPort=80
>>>>>>>> &IpPermissions.1.Groups.1.******GroupName=OtherAccountGroup
>>>>>>>> &IpPermissions.1.Groups.1.******UserId=999988887777
>>>>>>>> &IpPermissions.1.IpRanges.1.******CidrIp=192.0.2.0/24
>>>>>>>>
>>>>>>>>
>>>>>>>>   Looks ok to me. Did you try this code and have trouble
making a call
>>>>>>>>
>>>>>>> with
>>>>>>> these parameters (or were the effects of making such a call
>>>>>>> unexpected?)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   It doesn't look like a valid request according to the AWS definition
>>>>>>> (
>>>>>>>
>>>>>>>   http://docs.amazonwebservices.******com/AWSEC2/2011-01-01/**
>>>>>>>> APIReference/index.html?******ApiReference-query-**
>>>>>>>> AuthorizeSecurityGroupIngress.******html<http://docs.**
>>>>>>>> amazonwebservices.com/AWSEC2/****2011-01-01/APIReference/**index.**<http://amazonwebservices.com/AWSEC2/**2011-01-01/APIReference/index.**>
>>>>>>>> html?ApiReference-query-****AuthorizeSecurityGroupIngress.****html<
>>>>>>>> http://docs.**amazonwebservices.com/AWSEC2/**
>>>>>>>> 2011-01-01/APIReference/index.**html?ApiReference-query-**
>>>>>>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2011-01-01/APIReference/index.html?ApiReference-query-AuthorizeSecurityGroupIngress.html>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>   )
>>>>>>>>
>>>>>>>>
>>>>>>>>   Interesting - but am unable to determine which part of
the aws
>>>>>>>>
>>>>>>> definition
>>>>>>> makes the above a non-valid request? Can you be a little more
specific
>>>>>>> please?
>>>>>>>
>>>>>>> marios
>>>>>>>
>>>>>>>
>>>>>>>   Maybe I'm wrong?
>>>>>>>
>>>>>>>
>>>>>>>> -- SM
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 28, 2011 at 4:24 PM, Sang-Min
>>>>>>>> Park<sang-min.park@eucalyptus.
>>>>>>>> ***
>>>>>>>> *com<sang-min.park@eucalyptus.****com<sang-min.park@**eucalyptus.com<sang-min.park@eucalyptus.com>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    Sorry marios for my late response. What I meant was
not that
>>>>>>>> Eucalyptus
>>>>>>>>
>>>>>>>>   driver supports firewall now, but the issue is there for
me to
>>>>>>>>> implement
>>>>>>>>> it.
>>>>>>>>> Thanks for pointing out that AWS still has the old code.
I'll use
>>>>>>>>> that
>>>>>>>>> old
>>>>>>>>> methods to implement firewalls against Eucalyptus. It
will be uglier
>>>>>>>>> than
>>>>>>>>> your code though (multiple AWS invocation as you imagine).
>>>>>>>>>
>>>>>>>>> -- SM
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Jun 26, 2011 at 11:06 PM, marios@redhat.com<mandreou@**
>>>>>>>>> redhat.com<mandreou@redhat.com****>>wrote:
>>>>>>>>>
>>>>>>>>>   Hi Sang-Min,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 25/06/11 15:49, Sang-Min Park wrote:
>>>>>>>>>>
>>>>>>>>>>   FYI, I looked at the firewall implementation and
found that
>>>>>>>>>> there's
>>>>>>>>>> an
>>>>>>>>>>
>>>>>>>>>>   issue
>>>>>>>>>>> with Eucalyptus driver.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   I was confused at first by what you meant as
looking at Euca
>>>>>>>>>>> driver
>>>>>>>>>>>
>>>>>>>>>> there's no mention of firewalls yet (besides the
declaration of
>>>>>>>>>> 'feature
>>>>>>>>>> :instances, :firewalls')
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   Eucalyptus supports the old parameter convention
in
>>>>>>>>>>
>>>>>>>>>>   '********AuthorizeSecurityGroupIngress' action.
I'll try if I can
>>>>>>>>>>
>>>>>>>>>>> patch
>>>>>>>>>>> AWS to
>>>>>>>>>>> generate the old parameters as well as the new
one.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   OK: you shouldn't need to patch aws at all
- my additions to aws
>>>>>>>>>>>
>>>>>>>>>> added
>>>>>>>>>> the
>>>>>>>>>> new 'manage_security_group_********ingress' method,
BUT did not
>>>>>>>>>> remove
>>>>>>>>>> any
>>>>>>>>>> of
>>>>>>>>>> the old code. I'm not sure if thats what you meant
by 'generate the
>>>>>>>>>> old
>>>>>>>>>> parameters as well as the new one' but if you mean
that your Euca
>>>>>>>>>> setup
>>>>>>>>>> (or
>>>>>>>>>> Euca in general) relies on the old appoxy/aws interface
then your
>>>>>>>>>> existing
>>>>>>>>>> code should be fine - appoxy/aws gem has not removed
any of those
>>>>>>>>>> earlier
>>>>>>>>>> methods:
>>>>>>>>>>
>>>>>>>>>> 1.  authorize_security_group_********named_ingress
>>>>>>>>>> 2.  revoke_security_group_named_********ingress
>>>>>>>>>> 3.  authorize_security_group_IP_********ingress
>>>>>>>>>> 4.  revoke_security_group_IP_********ingress
>>>>>>>>>>
>>>>>>>>>> That being said, here's why I implemented the new
>>>>>>>>>> 'manage_security_groups'
>>>>>>>>>> method in the appoxy/aws gem: (https://github.com/appoxy/********<https://github.com/appoxy/******>
>>>>>>>>>> <https://github.com/appoxy/******<https://github.com/appoxy/****>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> aws/pull/91<https://github.****com/appoxy/**aws/pull/91<https**
>>>>>>>>>> ://github.com/appoxy/**aws/**pull/91<https://github.com/appoxy/**aws/pull/91>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> <http**s://github.<https://**github<https://github>.>**
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> com/appoxy/aws/pull/91<https:/****/github.com/appoxy/aws/pull/**91<http://github.com/appoxy/aws/pull/91>
>>>>>>>>>> <https://github.com/appoxy/**aws/pull/91<https://github.com/appoxy/aws/pull/91>
>>>>>>>>>>>
>>>>>>>>>> **>>):
>>>>>>>>>>
>>>>>>>>>> methods 1/2 above don't allow you to specify fine-grained
control
>>>>>>>>>> over
>>>>>>>>>> group
>>>>>>>>>> access - i.e. you can specify which groups to authorize,
but not
>>>>>>>>>> which
>>>>>>>>>> protocols/ports to allow for those groups. Also,
3/4 only allow you
>>>>>>>>>> to
>>>>>>>>>> specify a single IP range at a time - thus if a given
firewall rule
>>>>>>>>>> has
>>>>>>>>>> a
>>>>>>>>>> large number of address ranges then this operation
will need to be
>>>>>>>>>> done
>>>>>>>>>> for
>>>>>>>>>> each of those. Similarly, you can't specify both
groups AND IP
>>>>>>>>>> addresses
>>>>>>>>>> in
>>>>>>>>>> a single call (thus defining an entire firewall rule
with a single
>>>>>>>>>> call).
>>>>>>>>>>
>>>>>>>>>> The earlier implementations of appoxy/aws were based
on the 2009
>>>>>>>>>> version
>>>>>>>>>> of AWS API http://docs.amazonwebservices.****
>>>>>>>>>> ****com/AWSEC2/2009-07-15/**
>>>>>>>>>> APIReference/ApiReference-********query-******
>>>>>>>>>> AuthorizeSecurityGroupIngress.*****
>>>>>>>>>> ***html<http://docs.****amazonwe**bservices.com/**AWSEC2/**<http://bservices.com/AWSEC2/**>
>>>>>>>>>> <http://**amazonwebservices.com/AWSEC2/****<http://amazonwebservices.com/AWSEC2/**>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009-07-15/APIReference/******ApiReference-query-**
>>>>>>>>>> AuthorizeSecurityGroupIngress.******html<http://docs.**
>>>>>>>>>> amazonwebservices.com/AWSEC2/****2009-07-15/APIReference/**<http://amazonwebservices.com/AWSEC2/**2009-07-15/APIReference/**>
>>>>>>>>>> ApiReference-query-****AuthorizeSecurityGroupIngress.****html<
>>>>>>>>>> http://docs.**amazonwebservices.com/AWSEC2/**
>>>>>>>>>> 2009-07-15/APIReference/**ApiReference-query-**
>>>>>>>>>> AuthorizeSecurityGroupIngress.**html<http://docs.amazonwebservices.com/AWSEC2/2009-07-15/APIReference/ApiReference-query-AuthorizeSecurityGroupIngress.html>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>> In the latest version of API, you can specify
a number of IP
>>>>>>>>>> addresses, or
>>>>>>>>>>
>>>>>>>>>> groups, or mix of both, for which the specified rule
will apply.
>>>>>>>>>> You
>>>>>>>>>> can
>>>>>>>>>> now
>>>>>>>>>> also specify 'from_port' 'to_port' and 'protocol'
for ingress
>>>>>>>>>> groups
>>>>>>>>>> in
>>>>>>>>>> a
>>>>>>>>>> rule,
>>>>>>>>>>
>>>>>>>>>> marios
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   Sang-min
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 17, 2011 at 8:06 AM,<marios@redhat.com>
     wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   This patch uses the new 'Firewalls' collection
(I pushed that to
>>>>>>>>>>> trunk
>>>>>>>>>>>
>>>>>>>>>>>   today).
>>>>>>>>>>>> The create_instance operation for the ec2
driver takes an array
>>>>>>>>>>>> of
>>>>>>>>>>>> firewall
>>>>>>>>>>>> names
>>>>>>>>>>>> for the instance to be 'launched into'. Patch
includes:
>>>>>>>>>>>>
>>>>>>>>>>>> * necessary modifications to server.rb
>>>>>>>>>>>> * addition of 'firewalls' to the Instance
model
>>>>>>>>>>>> * modification of the haml views: html for
the create operation,
>>>>>>>>>>>> html/xml
>>>>>>>>>>>> for showing
>>>>>>>>>>>>   firewalls when inspecting a given instance.
>>>>>>>>>>>>
>>>>>>>>>>>> If you aren't using the html interface to
create an instance, you
>>>>>>>>>>>> can
>>>>>>>>>>>> specify
>>>>>>>>>>>> firewalls using form input : 'firewall#=name'
where '#' is any
>>>>>>>>>>>> digit.
>>>>>>>>>>>>   For
>>>>>>>>>>>> example:
>>>>>>>>>>>>
>>>>>>>>>>>> curl -F 'image_id=ami-48aa4921' -F 'firewalls1=default'
-F
>>>>>>>>>>>> 'firewalls2=test'
>>>>>>>>>>>>   --user 'ec2_key:ec2_password'
>>>>>>>>>>>> http://localhost:3001/api/********instances?format=xml<http://localhost:3001/api/******instances?format=xml>
>>>>>>>>>>>> <http://**localhost:3001/api/******instances?format=xml<http://localhost:3001/api/****instances?format=xml>
>>>>>>>>>>>>>
>>>>>>>>>>>> <http://**localhost:3001/api/******instances?format=xml<http:/**
>>>>>>>>>>>> /localhost:3001/api/****instances?format=xml<http://localhost:3001/api/**instances?format=xml>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   <http://**localhost:3001/api/****instances?**format=xml<http:/
>>>>>>>>>>>> **/**
>>>>>>>>>>>> localhost:3001/api/instances?****format=xml<http://localhost:**
>>>>>>>>>>>> 3001/api/instances?format=xml<http://localhost:3001/api/instances?format=xml>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> will create an instance from ami-48aa4921
and place it into
>>>>>>>>>>>> firewalls
>>>>>>>>>>>> 'default'
>>>>>>>>>>>> and 'test'. EC2 does not support 'moving'
an instance between
>>>>>>>>>>>> firewalls
>>>>>>>>>>>> once it's
>>>>>>>>>>>> launched so this functionality was not implemented
>>>>>>>>>>>> (http://aws.amazon.com/********articles/1145?_encoding=UTF8&***
>>>>>>>>>>>> *****<http://aws.amazon.com/******articles/1145?_encoding=UTF8&******>
>>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=**UTF8&****<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <http://aws.amazon.com/******articles/1145?_encoding=UTF8&******<http://aws.amazon.com/****articles/1145?_encoding=UTF8&****>
>>>>>>>>>>>> <http://aws.amazon.com/****articles/1145?_encoding=UTF8&****<http://aws.amazon.com/**articles/1145?_encoding=UTF8&**>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> jiveRedirect=1#13<http://aws.******amazon.com/articles/1145?_***
>>>>>>>>>>>> *<http://amazon.com/articles/1145?_**>
>>>>>>>>>>>> encoding=UTF8&jiveRedirect=1#******13<http://aws.amazon.com/**
>>>>>>>>>>>> articles/1145?_encoding=UTF8&****jiveRedirect=1#13<http://aws.**
>>>>>>>>>>>> amazon.com/articles/1145?_**encoding=UTF8&jiveRedirect=1#**13<http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedirect=1#13>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>   )
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> marios
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> ----------------------------------------------------
>> Sang-Min Park
>> Engineer
>> Eucalyptus Systems
>>
>>
>
>


Mime
View raw message