Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Allow to define a port range for custom_services #107

Closed
gothicx opened this issue Nov 29, 2016 · 4 comments
Closed

Feature: Allow to define a port range for custom_services #107

gothicx opened this issue Nov 29, 2016 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@gothicx
Copy link
Contributor

gothicx commented Nov 29, 2016

It would be nice to have :-)

firewalld::custom_services:
xy-application:
short: 'xy-application'
description: 'XY Application'
port:
- port: 5000:5020
protocol: 'tcp'

Then it will detect there is a ":" or "-" in the port variable and create the xml service accordingly.

@crayfishx crayfishx added enhancement New feature or request needs decision labels Nov 29, 2016
@crayfishx
Copy link
Contributor

@gothicx How do you see this working? A separate entry for each member of the port range? A quick glance at http://www.firewalld.org/documentation/service/options.html doesn't show any native support for port ranges for custom services, unless I'm not seeing it...

@gothicx
Copy link
Contributor Author

gothicx commented Nov 29, 2016

@crayfishx There is no official support, the idea is to have an entry in the port entry that provides a range and then the ruby code will parse that and transform into separated ports at service xml level.

You specify "port: 5000:5020", but in xml it will translate to one port per line. You see?

    <port protocol="tcp" port="5000" />
    <port protocol="tcp" port="5001" />
    <port protocol="tcp" port="5002" />
     ....

@crayfishx
Copy link
Contributor

The custom_service type already allows you to define multiple ports via a hash, so I guess we're not doing anything that different here, just allowing a short-hand expression in the way they are declared. This should be fairly easy to engineer.... Based on that, I think we can add this.

@crayfishx crayfishx added this to the 3.2.0 milestone Nov 29, 2016
@gothicx
Copy link
Contributor Author

gothicx commented Nov 29, 2016

Thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants