1. 22 Jan, 2020 1 commit
    • Jérome Perrin's avatar
      Fix missing rpath on proftpd · ff54662e
      Jérome Perrin authored
      Recent fixes for proftpd were still not correct, we still have issues with rpath for mod_auth_web and proftpd itself which uses libcap if available, error was:
          
          ======================================================================
          ERROR: setUpModule (test)
          ----------------------------------------------------------------------
          Traceback (most recent call last):
            File "/srv/slappart11/cqg/soft/1ae6b62cded47f49a2e77af2f372cf2a/parts/slapos.core-repository/slapos/testing/testcase.py", line 154, in setUpModule
              installSoftwareUrlList(cls, [software_url], debug=debug)
            File "/srv/slappart11/cqg/soft/1ae6b62cded47f49a2e77af2f372cf2a/parts/slapos.core-repository/slapos/testing/testcase.py", line 348, in installSoftwareUrlList
              raise e
          RuntimeError: /srv/slappart11/cqg/inst/test0-0/tmp/soft/728168be59c5353c6e3c6a6bc4cad052/parts/proftpd/bin/ftpdctl uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2 /srv/slappart11/cqg/inst/test0-0/tmp/soft/728168be59c5353c6e3c6a6bc4cad052/parts/proftpd/libexec/mod_auth_web.so has some not found libraries:
          /srv/slappart11/cqg/inst/test0-0/tmp/soft/728168be59c5353c6e3c6a6bc4cad052/parts/proftpd/libexec/mod_auth_web.so: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /srv/slappart11/cqg/inst/test0-0/tmp/shared/curl/da798e87b4f10345c33fbae0a4593114/lib/libcurl.so.4)
          /srv/slappart11/cqg/inst/test0-0/tmp/soft/728168be59c5353c6e3c6a6bc4cad052/parts/proftpd/sbin/proftpd uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
          /srv/slappart11/cqg/inst/test0-0/tmp/soft/728168be59c5353c6e3c6a6bc4cad052/parts/proftpd/sbin/in.proftpd uses system library /lib/x86_64-linux-gnu/libcap.so.2 for libcap.so.2
          Ran 0 tests in 530.067s
          ----------------------------------------------------------------------
      
      /reviewed-on nexedi/slapos!685
      ff54662e
  2. 17 Jan, 2020 4 commits
  3. 16 Jan, 2020 1 commit
  4. 15 Jan, 2020 6 commits
  5. 14 Jan, 2020 6 commits
    • Jérome Perrin's avatar
      Fix collective.recipe.shelloutput running "too early" · 3ba2ca38
      Jérome Perrin authored
      Our software using sshd were sometimes failing in tests, because the way they publish key fingerprint was racy.
      
      It is based on `collective.recipe.shelloutput`, which as we can see in the [recipe code](https://github.com/collective/collective.recipe.shelloutput/blob/78e15c19/collective/recipe/shelloutput/__init__.py) operates on `__init__`.
      
      We are using `collective.recipe.shelloutput` to capture the output of `ssh-keygen -lf $KEY` and this must run after the file `$KEY` is generated ( it is generated by another `plone.recipe.command` version). We were trying to run the `collective.recipe.shelloutput` after the `plone.recipe.command`, but that was incorrect anyway, because `collective.recipe.shelloutput` reads the file at `__init__` step, where `plone.recipe.command` creates the file at `install` step.
      As we could see in test suite, it was sometimes working, when `slapos node instance` ran only once, but it sometimes  working, when `slapos node instance` ran more than once, for example because a promise failed and `slapos node instance` was retried.
      
      Since `collective.recipe.shelloutput` does not take into account the exit code of the command but simply capture with `"Error ..."` whatever the command might output on stderr, we add another step checking that the captured output  is not `"Error ..."` and if it is cause a buildout error so that `slapos node instance` is retried and then succeed.
      
      What should happen now is:
       1. `collective.recipe.shelloutput` reads the key fingerprint, the file is not present so it captures `"Error ..."``
       2. a `plone.recipe.command` creates the key
       3. another `plone.recipe.command` checks that the captured fingerprint is not `"Error ..."` it fails
       4. buildout restarts
       5. `collective.recipe.shelloutput` reads key fingerprint correctly.
      
      Slaprunner has been heavily modified, because it was using a `sshkeys_authority` which was incompatible with this as it uses symlinks for keys. Since we don't know what is the purpose of `sshkeys_authority`, we rewrote that software to use simple commands instead of that "ssh keys authority".
      
      /reviewed-on !681
      3ba2ca38
    • Romain Courteaud's avatar
      2331b9d7
    • Romain Courteaud's avatar
      software/backupserver: first test · bb3ae5be
      Romain Courteaud authored
      bb3ae5be
    • Romain Courteaud's avatar
      2608cb7b
    • Romain Courteaud's avatar
      component/xwd: missing rpath · 2f1f4781
      Romain Courteaud authored
      2f1f4781
    • Romain Courteaud's avatar
      component/tomcat: version 7.0.99 · 75d73e97
      Romain Courteaud authored
      75d73e97
  6. 13 Jan, 2020 5 commits
  7. 07 Jan, 2020 1 commit
  8. 06 Jan, 2020 1 commit
    • Jérome Perrin's avatar
      component/qemu-kvm: add missing extends · 23c32192
      Jérome Perrin authored
      Now that component/glib/buildout.cfg is no longer included by pkgconfig,
      qemu no longer build with:
      
          While:
      	Installing.
      	Getting section template.
      	Initializing section template.
      	Getting section template-nbd.
      	Initializing section template-nbd.
      	Getting section kvm.
      	Initializing section kvm.
      	Getting option kvm:configure-options.
      	Getting section glib.
      	Error: The referenced section, 'glib', was not defined.
      
      Also explictly add pcre to prevent same problem later.
      23c32192
  9. 03 Jan, 2020 2 commits
    • Julien Muchembled's avatar
    • Julien Muchembled's avatar
      fixup! glib: put the expected python in $PATH · 77d9f997
      Julien Muchembled authored
      The OS may not have Python (slapos-node package does not depend
      on any version of Python). Another possible issue was found on Suse:
      
        make[3]: Entering directory '.../parts/glib__compile__/glib-2.56.4/gio'
          GEN      gdbus-daemon-generated.c
        Traceback (most recent call last):
          File "./gdbus-2.0/codegen/gdbus-codegen.in", line 53, in <module>
            from codegen import codegen_main
          File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/codegen_main.py", line 30, in <module>
            from . import parser
          File ".../parts/glib__compile__/glib-2.56.4/gio/gdbus-2.0/codegen/parser.py", line 23, in <module>
            import xml.parsers.expat
        ImportError: No module named xml.parsers.expat
      77d9f997
  10. 02 Jan, 2020 4 commits
  11. 31 Dec, 2019 1 commit
  12. 30 Dec, 2019 1 commit
    • Łukasz Nowak's avatar
      caddy-frontend: Set open files soft limit · 324c08d0
      Łukasz Nowak authored
      Caddy by itself does not raise soft limit of open files, so it has to be set
      by the wrapper.
      
      As slapos.cookbook:wrapper can't be used for such case, the
      slapos.recipe.template:jinja2 recipe inline style is used to have full
      control over the created wrapper.
      
      /reviewed-on nexedi/slapos!678
      324c08d0
  13. 27 Dec, 2019 2 commits
  14. 25 Dec, 2019 1 commit
  15. 24 Dec, 2019 2 commits
  16. 23 Dec, 2019 1 commit
  17. 18 Dec, 2019 1 commit
    • Jérome Perrin's avatar
      glib: put the expected python in $PATH · 6acdc8ca
      Jérome Perrin authored
      On testnodes, python can be too long for linux shebang (#!) line.
      
      We had for example:
          
          /srv/slapgrid/slappart15/srv/testnode/cqc/inst/test0-0/tmp/shared/python2.7/338ccc0e387d64185920266f8a97c87b/bin/python2.7
        
      
      that is 123 characters long.
      
      With this, the generated glib-genmarshall script will have:
          
          #!/usr/bin/env  /srv/slapgrid/slappart15/srv/testnode/cqc/inst/test0-0/tmp/shared/python2.7/338ccc0e387d64185920266f8a97c87b/bin/python2.7
      
      which exceeds the linux kernel limit.
      
      Instead, we generate scripts that will use
          
          #!/usr/bin/env python
      
      and it will be the caller responsibility to set $PATH to use the expected python.
      
      
      This fixes the issues we had on SlapOS.SoftwareReleases.IntegrationTest tests since we updated glib to 2.56.4 in a7a86db9
      
      /reviewed-on nexedi/slapos!670
      6acdc8ca