Bug 1452224 - Log Collection fails via IPv6
Summary: Log Collection fails via IPv6
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: GA
: 5.9.0
Assignee: Nick Carboni
QA Contact: Tasos Papaioannou
URL:
Whiteboard: ipv6:log_collect
Depends On:
Blocks: 1461161
TreeView+ depends on / blocked
 
Reported: 2017-05-18 15:43 UTC by Mike Shriver
Modified: 2018-03-06 15:13 UTC (History)
9 users (show)

Fixed In Version: 5.9.0.8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1461161 (view as bug list)
Environment:
Last Closed: 2018-03-06 15:13:01 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Mike Shriver 2017-05-18 15:43:06 UTC
Description of problem:
An IPv6 FTP server cannot be validated for log collection, and log collection via anonymous FTP fails with the same errors that validation fails with.

Two failure modes: 
1. URI parsing fails, error message: "bad URI(is not URI?)"
2. getaddrinfo call fails: getaddrinfo: Name or service not known

Failure mode 1:
If the address is entered into the URI field 'bare' (feed:beef::1) the 'validate' button results in this error message. Same error if anon-ftp is configured with no validation and a log collection is triggered.

Failuire mode 2:
If the address is entered in the URL field with the IPv6 URI delimiters ([feed:beef::1]), the validate button or anon-ftp collection results in a getaddrinfo failure.  I have tested with various delimiter escaping (\[, \\[), and these delimiters are getting parsed but are not handled correctly.  I can tell they're getting parsed because a form validated/saved with \[feed:beef::1\] shows modifications in the URL displayed in the GUI/log.


Version-Release number of selected component (if applicable):
5.8.0.13

How reproducible:
100%

Steps to Reproduce:
1. Deploy IPv6 appliance
2. Deploy IPv6 FTP server (used vsftpd on F25 for testing, should not matter)
3. Attempt to configure FTP server for log collection

Actual results:
Validation failure messages, two modes.

Expected results:
Validated authentication for FTP server, or anonymous connections over IPv6 when configured.

I do not expect that the user need to delimit their IPv6 addresses in the URI field, CFME should be able to detect the address type and apply the correct URL formatting.

Additional info:

Comment 4 CFME Bot 2017-06-12 18:41:19 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/65dd7a6559364a1ab1422341ce13ec0100465b53

commit 65dd7a6559364a1ab1422341ce13ec0100465b53
Author:     Šimon Lukašík <isimluk>
AuthorDate: Fri Jun 9 09:41:02 2017 +0200
Commit:     Šimon Lukašík <isimluk>
CommitDate: Fri Jun 9 09:41:02 2017 +0200

    Support IPv6 for log collection
    
    Unwrap [] parenthesis around IPv6 address
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1452224

 app/models/file_depot_ftp.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 6 Tasos Papaioannou 2017-10-13 14:44:11 UTC
Failed on 5.9.0.2.

When trying to create a log depot for Anonymous FTP, only the Type field is visible. The Depot Name and URI are all missing. When selecting the regular FTP type, the username and password-related fields (and Validate button) are also missing.

The same problems exists for all types except Red Hat Dropbox. Once Red Hat Dropbox is selected, the Depot Name and URI fields appear, and they stay visible when selecting any other type, but username and password-related fields are still missing for types that require them.

Comment 7 Nick Carboni 2017-11-15 19:51:48 UTC
Using version 5.9.0.8 I can see all the required fields for all the types of Log Depot.

Can you retest with that version Tasos?

Comment 8 Nick Carboni 2017-11-17 14:57:39 UTC
Moving this back to ON_QA as the issue reported seems to be resolved in 5.9.0.8.

Comment 9 Tasos Papaioannou 2017-11-20 15:41:29 UTC
Verified on 5.9.0.9.


Note You need to log in before you can comment on or make changes to this bug.