[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to get debian ci test passed for proxy application



On Mon, Dec 04, 2017 at 04:59:12PM +0100, gregor herrmann wrote:
> On Mon, 04 Dec 2017 22:45:21 +0900, Roger Shimizu wrote:
> 
> > On Mon, Nov 27, 2017 at 5:36 AM, gregor herrmann <gregoa@debian.org> wrote:
> > > On Sun, 26 Nov 2017 18:42:22 +0000, James Cowgill wrote:
> > >> I think you might need a "Restrictions: isolation-container" to get
> > >> network access, but that's only a guess.
> > > That's not my experience. We have quite a few perl packages where the
> > > tests do something networky and haven't experienced problems on
> > > ci.debian.net (modulo failing requests to external resources but
> > > that's of course a different story).
> > Maybe out bound network activity is OK, but not for open tcp port to
> > listen, as James said.
> 
> Sorry for being not more clear in my first mail: we also start all
> kinds of daemons, either from the package itself or some other
> packages (mysql, mariadb, memcached, …), and the tests successfully
> connect to them.

You do not need anything Restrictions: to be able to start a daemon or
listen on a local TCP port.

I tried the package locally both under autopkgtest+lxc, and on my host
system, and got the same results as the ones in ci.debian.net, i.e.
stuff like

running test:  python tests/test.py -c tests/chacha20-ietf-poly1305.json
*   Trying 127.0.0.1...
* TCP_NODELAY set
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* SOCKS5 communication to www.google.com:80
* SOCKS5 request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/7.57.0
> Accept: */*
>
* Empty reply from server
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server
test failed:  python tests/test.py -c tests/chacha20-ietf-poly1305.json


I tried messing with tests/test.py like this:

diff --git a/tests/test.py b/tests/test.py
index 0a1297b..ec8f3e3 100755
--- a/tests/test.py
+++ b/tests/test.py
@@ -60,9 +60,9 @@ if config.client_args:
     else:
         server_args.extend(config.client_args.split())

-p1 = Popen(server_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
-p2 = Popen(client_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
-p5 = Popen(tunnel_args, stdin=PIPE, stdout=PIPE, stderr=PIPE, close_fds=True)
+p1 = Popen(server_args, stdin=PIPE, close_fds=True)
+p2 = Popen(client_args, stdin=PIPE, close_fds=True)
+p5 = Popen(tunnel_args, stdin=PIPE, close_fds=True)
 p3 = None
 p4 = None
 p3_fin = False

and discovered that the test server is not listening to the port you think it is:

| $ ./tests/test.sh 
| running test:  python tests/test.py -c tests/aes.json
|  2017-12-04 16:07:02 INFO: UDP relay enabled
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 ERROR: bind: Address already in use
|  2017-12-04 16:07:02 ERROR: bind() error
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1081
|  2017-12-04 16:07:02 INFO: initializing ciphers... aes-256-cfb
|  2017-12-04 16:07:02 INFO: UDP relay enabled
|  2017-12-04 16:07:02 INFO: listening at 127.0.0.1:1082

                                                    ^^^^

| *   Trying 127.0.0.1...
| * TCP_NODELAY set
|   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
|                                  Dload  Upload   Total   Spent    Left  Speed
|   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* SOCKS5 communication to www.google.com:80
|  2017-12-04 16:07:04 INFO: connect to www.google.com:80
| * SOCKS5 request granted.
| * Connected to 127.0.0.1 (127.0.0.1) port 1081 (#0)
                                            ^^^^
| > GET / HTTP/1.1
| > Host: www.google.com
| > User-Agent: curl/7.57.0
| > Accept: */*
| > 
|  2017-12-04 16:07:04 ERROR: remote_recv_cb_recv: Connection reset by peer
| * Empty reply from server
|   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
| * Connection #0 to host 127.0.0.1 left intact
| curl: (52) Empty reply from server
|  2017-12-04 16:07:04 INFO: closed gracefully
| test failed:  python tests/test.py -c tests/aes.json

Why this happens? Because on autopkgtest, you assume the package is already
*installed*. I assume the the daemon provided by the binary package is already
listening to port 1081, so the test server starts on 1082.

In this case, I think you want connect to the daemon that is already running,
i.e. the one that is provided by the binary package, instead of some daemon
that is started by the test themselves.

the log from
http://debomatic-amd64.debian.net/distribution#unstable/shadowsocks-libev/3.1.1+ds-1/autopkgtest
seems truncated, but I would assume that the chroot being used there is
configured to not start services, what does not model the ideal environment
where you want to run autopkgtest: testbeds that look as much as possible as
regular systems, where daemons are started automatically, etc.

Attachment: signature.asc
Description: PGP signature


Reply to: