action #54338
closedrsync.pl on OSD is unable to access IBS: "@ERROR: access denied to trigger-repos-sync from UNKNOWN (2620:113:80c0:8080:5054:ff:fe49:b768)"
0%
Description
Observation¶
in /var/log/openqa_rsync.log:
Mon Jul 15 14:45:01 CEST 2019
Configured to deprioritize or cancel jobs from previous builds
@ERROR: access denied to trigger-repos-sync from UNKNOWN (2620:113:80c0:8080:5054:ff:fe49:b768)
rsync error: error starting client-server protocol (code 5) at main.c(1650) [Receiver=3.1.0]
Updated by okurz almost 5 years ago
I forced the sync and trigger of the current build for today with sudo -u geekotest /opt/openqa-scripts/rsync.pl --verbose sle12_sp5 on osd but do not plan myself to investigate further.
Updated by riafarov almost 5 years ago
So, the problem is that we cannot access ibs over ipv6, temporary patch is provided: https://gitlab.suse.de/openqa/scripts/merge_requests/354
Nick Singer will file infra ticket and once that is resolved, we can revert hot patch.
Updated by nicksinger almost 5 years ago
- Status changed from New to Blocked
https://infra.nue.suse.com/Ticket/Display.html?id=142342&results=31276bd3a92608248d63b414b5d32fd4 and since you can't see it:
Hey there,
starting from Monday, we can't access rsync://dist.suse.de/trigger-repos-sync any longer because openqa.suse.de now usesIPv6 to access the service. This results in an "access denied" message from rsyncd running on dist.
Please enable access over IPv6 too.
Thanks in advance,
Nick
Updated by okurz almost 5 years ago
- Assignee set to nicksinger
We found a good workaround by enforcing IPv4 so reducing prio.
@nicksinger as you are the only one from our side that has access to the ticket (I hate these ticket systems with no read access) you should be assignee to be able to update us on movement.
@riafarov @nicksinger thanks for a good teamwork on this, mob program everything! ;)
Updated by nicksinger almost 5 years ago
- Status changed from Blocked to Feedback
The new entry was added to the whitelist of dist.suse.de. However it requires us to change the outgoing v6 for OSD to the "official" one (was 2620:113:80c0:8080:5054:ff:fe49:b768 but needs to be 2620:113:80c0:8080:10:160:0:207).
I was able to archive this by using the following command: ip -6 r a default via fe80::1 src 2620:113:80c0:8080:10:160:0:207 dev eth0 metric 1. However, nobody really knows where the wrong ip comes from in the first place. According to /etc/sysconfig/network/ifcfg-eth0 we should only have the "official" v6 on that host.
The question now is if we can figure out what gives us this (dhcp'ish looking) v6 and if not, how to configure the above ip -6 r a command on boot.
Updated by okurz over 4 years ago
- Blocked by action #57233: Properly handle transport errors in ObsRsync plugin added
Updated by okurz over 4 years ago
- Status changed from Feedback to Blocked
- Assignee set to okurz
Updated by andriinikitin over 4 years ago
- Blocked by deleted (action #57233: Properly handle transport errors in ObsRsync plugin)
Updated by okurz over 4 years ago
- Related to action #57233: Properly handle transport errors in ObsRsync plugin added
Updated by okurz over 4 years ago
- Status changed from Blocked to New
- Assignee deleted (
okurz)
The relation to #57233 was added under the general assumption that obsrsync should fully replace rsync.pl and hence solve all problems – or at least inherit them ;)
@nicksinger I can see that https://infra.nue.suse.com/SelfService/Display.html?id=142342 was set to "resolved", it does not look like anyone changed something in the infrastructure. As I know that a proper network infrastructure is also close to your heart, can you state what you think should be done as next step?
Updated by okurz about 4 years ago
- Status changed from New to Rejected
- Assignee set to okurz
No response. I guess we will just see if obsrsync shows this problem or not.