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 <module> > 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 <module> > 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
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.
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).
--
Evilham
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
