Re: [DNG] Python modules SimpleHTTPServer / SocketServer
On Sun, 12 Aug 2018 19:53:43 +0200 Evilham wrote: [snip] > This may be the place you reached: this now runs a web server, > leave this command running. Thanks! That's the bit that counts... [snip] > 4. Edit lib/debian-releases.mk accordingly > 5. Check if it works with devuan config, basically repeat 2. It does. [snip] > Also notice that if you want, you can just git clone my repository and > follow 2. (the commands do take "forever" :-D so do that if you trust > what I did, which maybe you should not as you may have read more about > this!). Reading is one thing, knowing what you're doing is another... > > Another interesting thing is that in 2.d I used /oldstable to test, > since that was "jessie" in both Debian and Devuan, /stable returns no > entries (which is wrong!) it may have something to do with > /data/config.json or sth like that, I'll leave that for your further > testing I've managed to get some of these pages filled with data. >(you have write permissions to that repo, so please update > that if you make progress). I have cloned it, and made a few commits. The devuan version looks devuanized: although there are some empty pages, some of them appear to be where they should be e.g. bugs for ascii-backports. > If we are going to use this, we want to merge back to Debian's repo as > much as possible to minimise long-term maintenance overhead; that > means some refactoring because, of course, this is built with a very > specific Debian-only mindset. > Ideally running this ends up being a matter of cloning upstream, > adding a config file or (some) env var(s) and that's it, i.e.: no > fiddling with Makefiles and the likes. I'd be happy to do what I can. > That may prove to be unrealistic since along with the software, there > is a bunch of data in the same repository and their workflow appears > to take advantage of that. I am certain you will know better than > me :-). > > If you need any more help, just reply (but make sure you CC me :-D). Many Thanks. Please let me know what next steps would be most helpful towards turning this into a useful tool. Perhaps the question that is uppermost in my mind is how to verify that the new database contains the correct combinations of packages, bugs and patches, i.e. is it trustworthy. Thanks again for your most helpful advice. leloft ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Python modules SimpleHTTPServer / SocketServer
Am 12.08.2018 um 13:12 schrieb leloft:
> Hello to everyone,
>
> I am trying to build a devuanized version of the debian
> security-tracker, but I have strayed very far from my skills base!
> Give or take a few untidy loose ends inherited from the
> debian oldoldstable and lts sections of the Makefile, the security
> database appears to build ok with devuan variables. I can confirm this
> in principle by cursory examination of a text file dump of the contents;
> as this file is >300Mb, this is hopelessly inadequate, but so
> far, so good.
>
> However, the process is halting at the creation of the python server.
> The problem is the same in 4 environments, and is the same with ordinary
> user and root privileges:
>
> 1) a headless 'dist-upgraded' ascii environment,
> 2) a chrooted 'minbase' ascii environment and
> 3) a chrooted 'minbase' debian stretch environment
> 4) a desktop machine running a 'dist-upgraded' ascii,
>
> Specifically, the process hangs during the
> SocketServer process:
>
> ^CTraceback (most recent call last):
> File "tracker_service.py", line 1773, in
> TrackerService(socket_name, db_name).run()
> File "../lib/python/web_support.py", line 840, in run
> self.server.serve_forever()
> File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever
> poll_interval)
> File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry
> return func(*args)
> KeyboardInterrupt
>
> The problem can be reproduced with this command
>
> $ python -m SimpleHTTPServer
>
> Serving HTTP on 0.0.0.0 port 8000 ...
> ^CTraceback (most recent call last):
> File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
> exec code in run_globals
> File "/usr/lib/python2.7/SimpleHTTPServer.py", line 235, in
> test()
> File "/usr/lib/python2.7/SimpleHTTPServer.py", line 231, in test
> BaseHTTPServer.test(HandlerClass, ServerClass)
> File "/usr/lib/python2.7/BaseHTTPServer.py", line 610, in test
> httpd.serve_forever()
> File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever
> poll_interval)
> File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry
> return func(*args)
> KeyboardInterrupt
>
> Has anyone any experience of whether these commands work/have worked
> 'out of the box' for them in an ascii installation? I cannot find any
> posts online that report any problems with the module, so I am assuming
> it is unique to me, unless someone has reproduced it on a different
> ascii machine.
>
> Ideas and insights or workarounds would be very welcome.
>
> Many Thanks
>
> leloft
>
<3 I've been following your DSA work, that's very awesome, thank you!
I just gave it a go on a (fresh-ish) VM and it appears to work:
0. apt-get install git make python-{apt,apsw}
1. git clone
https://salsa.debian.org/security-tracker-team/security-tracker.git
2 test that it works with debian config:
2.a make update-packages
2.b make
2.c make serve
This may be the place you reached: this now runs a web server,
leave this command running.
2.d curl http://127.0.0.1:10605/tracker/status/release/oldstable | less
This should show you a bunch of HTML with some CVE data.
2.e Finish the make serve command (CTRL+C)
2.f make clean
3. Edit Makefile accordingly
4. Edit lib/debian-releases.mk accordingly
5. Check if it works with devuan config, basically repeat 2.
For the changes I made in steps 3 and 4 check:
https://git.devuan.org/evilham/security-tracker/commit/2515688e17116ee28b735fc85df9a18fab6a44bd
Notice that they reflect the different repo structure for Devuan (also
that I left only one .mk file, having multiple leads to make warnings).
To keep the scripts happy, I also limited the architectures listed, e.g.
there is no ascii-updates/non-free/binary-mips in our repos.
@parazyd: is this a bug in Amprolla or is it by design? Would it make
sense to create an "empty" repository in those cases? I know this is
easily patchable in these scripts, but *maybe* it is a desirable thing
for Amprolla as a whole and is not too difficult.
Also notice that if you want, you can just git clone my repository and
follow 2. (the commands do take "forever" :-D so do that if you trust
what I did, which maybe you should not as you may have read more about
this!).
Another interesting thing is that in 2.d I used /oldstable to test,
since that was "jessie" in both Debian and Devuan, /stable returns no
entries (which is wrong!) it may have something to do with
/data/config.json or sth like that, I'll leave that for your further
testing (you have write permissions to that repo, so please update that
if you make progress).
If we are going to use this, we want to merge back to Debian's repo as
much as possible to minimise long-term maintenance overhead; that means
some refactoring because, of course, this is built with a very specific
[DNG] Python modules SimpleHTTPServer / SocketServer
Hello to everyone, I am trying to build a devuanized version of the debian security-tracker, but I have strayed very far from my skills base! Give or take a few untidy loose ends inherited from the debian oldoldstable and lts sections of the Makefile, the security database appears to build ok with devuan variables. I can confirm this in principle by cursory examination of a text file dump of the contents; as this file is >300Mb, this is hopelessly inadequate, but so far, so good. However, the process is halting at the creation of the python server. The problem is the same in 4 environments, and is the same with ordinary user and root privileges: 1) a headless 'dist-upgraded' ascii environment, 2) a chrooted 'minbase' ascii environment and 3) a chrooted 'minbase' debian stretch environment 4) a desktop machine running a 'dist-upgraded' ascii, Specifically, the process hangs during the SocketServer process: ^CTraceback (most recent call last): File "tracker_service.py", line 1773, in TrackerService(socket_name, db_name).run() File "../lib/python/web_support.py", line 840, in run self.server.serve_forever() File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever poll_interval) File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry return func(*args) KeyboardInterrupt The problem can be reproduced with this command $ python -m SimpleHTTPServer Serving HTTP on 0.0.0.0 port 8000 ... ^CTraceback (most recent call last): File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/SimpleHTTPServer.py", line 235, in test() File "/usr/lib/python2.7/SimpleHTTPServer.py", line 231, in test BaseHTTPServer.test(HandlerClass, ServerClass) File "/usr/lib/python2.7/BaseHTTPServer.py", line 610, in test httpd.serve_forever() File "/usr/lib/python2.7/SocketServer.py", line 231, in serve_forever poll_interval) File "/usr/lib/python2.7/SocketServer.py", line 150, in _eintr_retry return func(*args) KeyboardInterrupt Has anyone any experience of whether these commands work/have worked 'out of the box' for them in an ascii installation? I cannot find any posts online that report any problems with the module, so I am assuming it is unique to me, unless someone has reproduced it on a different ascii machine. Ideas and insights or workarounds would be very welcome. Many Thanks leloft ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
