[opensuse-buildservice] Problems after update to 2.9.2

Hi, begin of this week I updated our private instance of OBS from 2.8.4 to 2.9.2. First tests did not show any issues, builds were running just fine. But after adding a new worker (no package cache !) we get build errors, in the build log we see that getbinaries did fail for the basic system packages (but the files are available and the packages do not have any unresolved state. In the repo server log I see the GET /getbinaries request and then a POST with failed status, nothing more. With Wireshark I saw that the answer for the /getbinaries request do contain info with "file is a symlink". Our base OS repositories are created from loop mounted Product DVDs or a local SMT copy, all packages are sym linked to the :full/ directory of the project, since we are in a fully isolated network. This setup did work without any issues for some years until now and I know some other private installations which use a similar bootstrapping method for the basic repositories. Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me. Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ? Thanks Karsten The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Freitag, 8. Juni 2018, 15:31:59 CEST wrote Keil, Karsten:
Hi,
begin of this week I updated our private instance of OBS from 2.8.4 to 2.9.2. First tests did not show any issues, builds were running just fine. But after adding a new worker (no package cache !) we get build errors, in the build log we see that getbinaries did fail for the basic system packages (but the files are available and the packages do not have any unresolved state. In the repo server log I see the GET /getbinaries request and then a POST with failed status, nothing more. With Wireshark I saw that the answer for the /getbinaries request do contain info with "file is a symlink". Our base OS repositories are created from loop mounted Product DVDs or a local SMT copy, all packages are sym linked to the :full/ directory of the project, since we are in a fully isolated network. This setup did work without any issues for some years until now and I know some other private installations which use a similar bootstrapping method for the basic repositories.
Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me.
Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ?
This is considered to be a security feature from our side. We could make it configurable though. This kind of setup is not really 100% supported atm, is there any reason why you don't just use DoD functionality? -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Hi,
On 8. Jun 2018, at 15:50 , Adrian Schröter <adrian@suse.de> wrote:
begin of this week I updated our private instance of OBS from 2.8.4 to 2.9.2. First tests did not show any issues, builds were running just fine. But after adding a new worker (no package cache !) we get build errors, in the build log we see that getbinaries did fail for the basic system packages (but the files are available and the packages do not have any unresolved state. In the repo server log I see the GET /getbinaries request and then a POST with failed status, nothing more. With Wireshark I saw that the answer for the /getbinaries request do contain info with "file is a symlink". Our base OS repositories are created from loop mounted Product DVDs or a local SMT copy, all packages are sym linked to the :full/ directory of the project, since we are in a fully isolated network. This setup did work without any issues for some years until now and I know some other private installations which use a similar bootstrapping method for the basic repositories.
Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me.
Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ?
This is considered to be a security feature from our side. We could make it configurable though.
This kind of setup is not really 100% supported atm, is there any reason why you don't just use DoD functionality?
This problem would hit us also. We're using DoD for recent versions, but we also have a bunch of legacy stuff with a similar symlink strategy. -- kind regards, Carsten Hoeger Professional Services Email: carsten.hoeger@open-xchange.com ------------------------------------------------------------------------------ Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Director: Frank Hoberg US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA ------------------------------------------------------------------------------ -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Hi, Adrian thanks for the quick answer. On Freitag, 8. Juni 2018, 15:51:30 CEST wrote Schröter,Adrian:
On Freitag, 8. Juni 2018, 15:31:59 CEST wrote Keil, Karsten:
Hi,
begin of this week I updated our private instance of OBS from 2.8.4 to 2.9.2. First tests did not show any issues, builds were running just fine. But after adding a new worker (no package cache !) we get build errors, in the build log we see that getbinaries did fail for the basic system packages (but the files are available and the packages do not have any unresolved state. In the repo server log I see the GET /getbinaries request and then a POST with failed status, nothing more. With Wireshark I saw that the answer for the /getbinaries request do contain info with "file is a symlink". Our base OS repositories are created from loop mounted Product DVDs or a local SMT copy, all packages are sym linked to the :full/ directory of the project, since we are in a fully isolated network. This setup did work without any issues for some years until now and I know some other private installations which use a similar bootstrapping method for the basic repositories.
Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me.
Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ?
This is considered to be a security feature from our side. We could make it configurable though.
That would be perfect.
This kind of setup is not really 100% supported atm, is there any reason why you don't just use DoD functionality?
For new projects (SLE12) we already switched to DoD. For the old legacy stuff we did this setup at the beginning (7 years ago) and it was just working fine and it was easy to handle. Maybe we can change it to some DoD setup too - but I fear this could cause some rebuilds (which end up in some extra deployments). If we can avoid this would be the best. Karsten Keil The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Hi Adrian, On 08.06.2018 15:50, Adrian Schröter wrote:
On Freitag, 8. Juni 2018, 15:31:59 CEST wrote Keil, Karsten>> Digging a little bit deeper in the repo server backend code, I found that some special handling for symlinks was introduced
In the BSHTTP::cpio_sender function and that the function has some support do follow symlinks, but this was not enabled in the calling function BSServer::reply_cpio, adding 'follow' => 1 as parameter to the call of BSHTTP::cpio_sender seems to fix this problem for me.
Questions: Is this valid as fix for now ? Is this a bug or is here some reason to forbid following symlinks ?
This is considered to be a security feature from our side. We could make it configurable though.
How is this affecting security? If I can create symlinks in /srv/obs/build/$project/$repo/$arch/:full/ on the build server, I can surely also patch out that check in BSHTTP.pm (as I'm doing right now ;-))
This kind of setup is not really 100% supported atm, is there any reason why you don't just use DoD functionality?
DoD just wastes space. DoD does not support file:// urls. Common setup: * have a SMT mirror of $ALL_SUSE_PRODUCTS on a NFS share. * mount that NFS share to /smtrepos * symlink everything into /srv/obs/build/.../:full/ * party on. I do this for all the SLE GM repos, and only DoD the update repos, because (if they are working correctly... ;)) I won't have to trigger new links / repo rescans manually. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (4)
-
Adrian Schröter
-
Carsten Höger
-
Keil, Karsten
-
Stefan Seyfried