You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2015/07/17 22:41:13 UTC
openIptables with BYON machines: add to SoftwareProcess?
Hi all,
A customer is using a bring-your-own-node location, and wants to use
something akin to the JcloudsLocation's openIptables. In
JcloudsLocation, it will look at the inboundPorts configuration, and
open those ports in the iptables rules on the OS.
A fundamental question... is this the responsibility of the location, or
should this be in the entity (i.e. the location just does cloud config +
setup of the initial user, and then hands over the VM; whatever is on
the actual OS is the responsibility of the entity)?
I favour adding to SoftwareProcess the config keys:
* openIptables (default true)
* stopIptables (default false)
* dontRequireTtyForSudo (default false - see
BashCommands.dontRequireTtyForSudo for details)
These would be the first things done by the SoftwareProcess (prior to
executing the pre-install commands). The SoftwareProcess has access to
the inboundPorts (it passed those in when obtaining the machine).
Does this sound sensible? Comments much appreciated!
Aled
Re: openIptables with BYON machines: add to SoftwareProcess?
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
True, but in that case I think whoever is putting both entities in the
same location is responsible for their configuration.
Sam
On 21/07/2015 12:50, Yavor Yanchev wrote:
> Hi,
>
> Can including openIptables on the SoftwareProcess cause some
> interference between different entities running on the same location?
>
> If one process has openIptables set to false, but some other changes
> it to true. Isn't the location a more suitable place to handle single
> configuration for multiple entities?
>
> Regards,
> Yavor
>
> On 07/20/2015 01:01 PM, Sam Corbett wrote:
>> Hi Aled,
>>
>> I favour including these parameters on the entity. Presumably it is the
>> software process being modelled that requires iptables opened or
>> stopped.
>>
>> Sam
>>
>>
>> On 17 July 2015 at 21:41, Aled Sage <al...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> A customer is using a bring-your-own-node location, and wants to use
>>> something akin to the JcloudsLocation's openIptables. In
>>> JcloudsLocation,
>>> it will look at the inboundPorts configuration, and open those ports
>>> in the
>>> iptables rules on the OS.
>>>
>>> A fundamental question... is this the responsibility of the
>>> location, or
>>> should this be in the entity (i.e. the location just does cloud
>>> config +
>>> setup of the initial user, and then hands over the VM; whatever is
>>> on the
>>> actual OS is the responsibility of the entity)?
>>>
>>> I favour adding to SoftwareProcess the config keys:
>>>
>>> * openIptables (default true)
>>> * stopIptables (default false)
>>> * dontRequireTtyForSudo (default false - see
>>> BashCommands.dontRequireTtyForSudo for details)
>>>
>>> These would be the first things done by the SoftwareProcess (prior to
>>> executing the pre-install commands). The SoftwareProcess has access
>>> to the
>>> inboundPorts (it passed those in when obtaining the machine).
>>>
>>> Does this sound sensible? Comments much appreciated!
>>>
>>> Aled
>>>
>>>
>
>
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: openIptables with BYON machines: add to SoftwareProcess?
Posted by Yavor Yanchev <ya...@yanchev.com>.
Hi,
Can including openIptables on the SoftwareProcess cause some
interference between different entities running on the same location?
If one process has openIptables set to false, but some other changes it
to true. Isn't the location a more suitable place to handle single
configuration for multiple entities?
Regards,
Yavor
On 07/20/2015 01:01 PM, Sam Corbett wrote:
> Hi Aled,
>
> I favour including these parameters on the entity. Presumably it is the
> software process being modelled that requires iptables opened or stopped.
>
> Sam
>
>
> On 17 July 2015 at 21:41, Aled Sage <al...@gmail.com> wrote:
>
>> Hi all,
>>
>> A customer is using a bring-your-own-node location, and wants to use
>> something akin to the JcloudsLocation's openIptables. In JcloudsLocation,
>> it will look at the inboundPorts configuration, and open those ports in the
>> iptables rules on the OS.
>>
>> A fundamental question... is this the responsibility of the location, or
>> should this be in the entity (i.e. the location just does cloud config +
>> setup of the initial user, and then hands over the VM; whatever is on the
>> actual OS is the responsibility of the entity)?
>>
>> I favour adding to SoftwareProcess the config keys:
>>
>> * openIptables (default true)
>> * stopIptables (default false)
>> * dontRequireTtyForSudo (default false - see
>> BashCommands.dontRequireTtyForSudo for details)
>>
>> These would be the first things done by the SoftwareProcess (prior to
>> executing the pre-install commands). The SoftwareProcess has access to the
>> inboundPorts (it passed those in when obtaining the machine).
>>
>> Does this sound sensible? Comments much appreciated!
>>
>> Aled
>>
>>
Re: openIptables with BYON machines: add to SoftwareProcess?
Posted by Sam Corbett <sa...@cloudsoftcorp.com>.
Hi Aled,
I favour including these parameters on the entity. Presumably it is the
software process being modelled that requires iptables opened or stopped.
Sam
On 17 July 2015 at 21:41, Aled Sage <al...@gmail.com> wrote:
> Hi all,
>
> A customer is using a bring-your-own-node location, and wants to use
> something akin to the JcloudsLocation's openIptables. In JcloudsLocation,
> it will look at the inboundPorts configuration, and open those ports in the
> iptables rules on the OS.
>
> A fundamental question... is this the responsibility of the location, or
> should this be in the entity (i.e. the location just does cloud config +
> setup of the initial user, and then hands over the VM; whatever is on the
> actual OS is the responsibility of the entity)?
>
> I favour adding to SoftwareProcess the config keys:
>
> * openIptables (default true)
> * stopIptables (default false)
> * dontRequireTtyForSudo (default false - see
> BashCommands.dontRequireTtyForSudo for details)
>
> These would be the first things done by the SoftwareProcess (prior to
> executing the pre-install commands). The SoftwareProcess has access to the
> inboundPorts (it passed those in when obtaining the machine).
>
> Does this sound sensible? Comments much appreciated!
>
> Aled
>
>
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.