It should skip image importing instead of raising exception and aborting if files are empty/unrecognized
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu system image |
New
|
Undecided
|
Unassigned |
Bug Description
Sometimes it may happen that SIS will try to fetch a file (via the http generator) and it won't verify it for real so it's possible the file is just an Apache error in HTML in disguise or whatever (because of ${reasons}). SIS will try to import it anyway and once it tries to use that file again to generate deltas it explodes similar to this:
2015-03-24 12:48:36,428 DEBUG Unxzipping file: /tmp/tmpGcbK6A/
xz: /srv/sis.
2015-03-24 12:48:36,431 DEBUG Unxzipping file: /tmp/tmpGcbK6A/
xz: /srv/sis.
Traceback (most recent call last):
File "/srv/system_
abspath)
File "/srv/system_
os.
File "/srv/system_
self.
File "/usr/lib/
return func(name, filemode, fileobj, **kwargs)
File "/usr/lib/
return cls(name, mode, fileobj, **kwargs)
File "/usr/lib/
self.
File "/usr/lib/
raise ReadError("empty file")
tarfile.ReadError: empty file
I have caught this when testing SIS with Capomastro but I hadn't had the chance to write a patch yet, so I'm just reporting it here to have some history of the problem. IMHO SIS should simply log or mark, then skip this image and not abort with an exception, which will block processing for all others images configured in the server.
One additional thing we noticed is that the http generator is very naive in that it assumes *anything* it downloaded (be it a 404 error page, or perhaps a gz-format file, or anything else you point it to) is actually a .xz in disguise. It blindly trusts the user and will simply rename (to $name-$ checksum. tar.xz) and place in the pool the given file.
This leads to the above error or similar when generating deltas, because the generate_delta method also assumes that it will only ever deal with xz files (does tools.xz_uncompress without catching exceptions or checking actual magic or mime types).
I think the http generator could check the file to ensure it's .xz actually, and if it isn't, output a message and discard the file. Otherwise the pool gets quite messed up. It's worth looking at our expectations for files in the pool (i.e. are they always xz'd tars?) so maybe http generator could further validate them.