sos clean should obfuscate hostnames like dhcp-192-168-0-66 #3388
Comments
|
Generally ACK, I noticed failed avocado tests on testing farms due to such hostnames. While strictly speaking the We should be careful with the change not to start obfuscating e.g. package names (e.g. |
|
We're already skipping multiple files, that have package names in the |
|
To make it clear, the failing test reports this, the fact that the hostname (containing the ip address) is present in the journal logs. It will echo everything that has the ip address, and in this case, since it passes with dashes (grep -rI will take regex so dashes seem to pass) I'm not sure, but should we be obfuscating hostnames anyway? Or is that only when the admin adds it to the hostname map manually before collecting sos? |
|
That is exactly the same scheme of the test failure I noticed as well :) The trick why hostname parser does not clean it is because the parser gets hostnames "just" from (*) at least that was my use case; yours looks like you have changed hostname to |
|
Yes its indeed strange because according to my use-case those logs should have had the hostname obfuscated. The hostname of the system is host-10-43-136-14 iiuc, and it shows up in the logs that hostnamed puts in the journal when it changed to that hostname. Seems like an all out bug then, and not a question of "adding this use case" to the cleaner scenarios because I thought the IP address was leaking, but actually its the hostname thats leaking. But whats even stranger is, if we take a closer look at the debian autopkgtests and what they're doing, the mask tests are, So now I am confused about why the first hostname obfuscation scenario checks just for host0 and not the actual hostname, perhaps this ubuntu autopkgtest is out of date and needs updating! So I tried reproducing this, to make sure, I copied the obfuscated sos in a new folder, tar xf'd it, What am I missing here? Or is cleaner broken? Is the cleaner NOT supposed to obfuscate the hostname from the logs? If I look at the private map file, |
|
@pmoravec Does this look like a cleaner bug to you where in fact the hostname (and not the ip addr) isnt getting obfuscated? |
|
@TurboTurtle , regarding your comment on IRC, yes it reproduces for a hostname that is "abc-something-not-ipaddress" |
|
Ok, so we have a generalized bug with the hostname parser regex. I'll spend some time over the next few days/weekend to see if I can refine that to address this. |
|
Oh, actually I see it now. The hostname in this example ( If you set the hostname to So this isn't a straight regex issue but rather one in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As seen in https://access.redhat.com/solutions/5154441 , dhcp often sets hostnames using the numeric parts of the IP address separated by dashes. The cleaner should obfuscate this kind of hostname because the ip address is getting leaked with dashes instead of dots. This has been frequently flagged in Ubuntu autopkgtests.
The sos cleaner regex for IP address is , looking at https://github.com/sosreport/sos/blob/main/sos/cleaner/parsers/ip_parser.py#L15C1-L22C6 ,
class SoSIPParser(SoSCleanerParser):
"""Handles parsing for IP addresses"""
I think we should also consider non dash characters, to catch leaks like an ip address for eg like w.x.y.z. leaking like something-w-x-y-z when dhcp seems to set the hostnames this way.
The text was updated successfully, but these errors were encountered: