https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c1 --- Comment #1 from Scott Couston 2012-05-03 07:13:46 UTC --- Created an attachment (id=489313) --> (http://bugzilla.novell.com/attachment.cgi?id=489313) more if you would like images or ask for logs IF you cannot duplicate the issue -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c3 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |scott@aphofis.com InfoProvider|scott@aphofis.com | --- Comment #3 from Scott Couston 2012-05-04 05:28:28 UTC --- Yes, standard error box from Online Update CANNOT ACCESS INSTALLATION MEDIA HTTP://DOWNLOAD.OPENSUSE.ORG/UPDATE/11.4/ UPDATES FOR OPENSUSE 11.4 11.4-0 (MEDIUM 1) CHECK WHETHER THE SERVER IS ACCESSIBLE... The URL has a .DRPM extension BUT the file exists as a .RPM only...In changing to a .DRPM file extension and format works well for 12.x....but retrospectively changing this backways, where only the .RPM file exists in the 11.4 repository. Some repositories have both the .RPM and the .DRPM file format in the repository and others only either A .DRPM OR a .DRPM file extension. In retrospect I dont think anyone should have attempted to apply the .DRPM file format retrospectively to versions below 12.1 - Its a disaster ...The easiest way to see this catastrophe is to do a non automated 11.4 KDE vanilla install....You’ll see it for yourself when all patch/online updates TRY to be performed. As such, as most all of the patch updates that are necessary to stabilise the version are not carried out as the file they call doesn’t exist with the correct extension. I'm on an X_64 Install, dont know what type of mess I586 or versions 11.0-11.4 are in as far as update repositories...I havn't even got to adding community repositories for auto video updates from Nvidia or sound or KDE updates or Mozilla Updates and god know what else...a retrospective DRPM file format replacement that has been initiated for past versions to 12.1 should be backed out as soon as possible...This is very ugly...sorry guys its that bad -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c5 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Marcus Meissner 2012-05-04 08:15:19 UTC --- download.opensuse.org was partially down this week, this was the most likely reason for the error you saw. the .drpm files are "delta rpm" files, that are there for saving bandwith for downloading updates. they will reassemble with installed files to the original RPM. These are _additionaly_ available, the full RPMs are still there and used if something is not found right. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c7 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #7 from Scott Couston 2012-05-13 04:58:31 UTC --- If a version comes out with .DRPM let the repos be DRPM. Now new distros that contain all .DRPM let their repos reflect the same .DRPM no problem. This is where we as professionals back out retrospective changes to existing versions and as it does no some the file that is call is .DRPM and not listed and there other was around. Its not fix in my 11.4 X64 download.opensuse.org/ This was lousy to bake retrospective change and this is where our profession IT staff...say back the retro regard that was perfectly o.k until you stuffed it up! Fix it or close this and make a concise why you cannot provide the most technical and expedient fix -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c8 --- Comment #8 from Scott Couston 2012-05-21 07:33:03 UTC --- Sorry, I was a bit harsh in the above text and not very helpful - I am doing a complete fresh install of 11.4 X64 to capture new audit trails to assist in fixing this issue still present on Mon, 21 May 20.12 17:28 Local GMT+10. I will attach the yast log files overnight so more debuging can go on. If you would like more that that yast2 log files can you please let me know asap...I am going to keep this complete test install available for the next +7 days so I can provide more info or log files..Its very frustrating not having basic update OSS files available at this late stage, well after initial problems.....Meanwhile I emailed your web-master as of the same data time with...

...

...

Probably the easiest way to see and workout the continuing problems with the 11.4 X_64 Repo would be to perform a basic non-automotive install of 11.4 X_64 KDE.

As soon as the Online update is stared the third file requested is not valid, or does not exist ...whatever.. This first file to be updated is the satsolver tools .DRPM which installs o.k Then the second file, the python-satsolver Fails!!!!!!!! The fourth file fails, the libzypp ...and needs to be skipped...I am on local time @Monday, 21 May 17.21 GMT+10..... Part of the other problems with various updates files is the sheer number of files in some of the directories. Mostly the files do exist, however the huge number of files cannot easily be completely read due incomplete caching of the directory. Often a retry will succeed as there has been more time to access the complete directories files. After I adjusted the traffic shaping from the pipe I have to demand the lowest traffic bandwidth of 8Mg/4.5Mg; the full contents listing on my screen from some of the larger directories,takes so long on first read that the files cannot be seen. After an auto retry where the directory is cached, everything goes without issue - but I'm on a pipe and I would hate to see how many retries are required to fully cache directories where speed is nominal!l Let me know if I can help further to rectify the continuing problems that still exist weeks and weeks after the .DRPM and redir update problems...

...

...

...

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c10 --- Comment #10 from Scott Couston 2012-05-22 03:29:18 UTC --- Created an attachment (id=491840) --> (http://bugzilla.novell.com/attachment.cgi?id=491840) .tar.gz for al Y2log files There are probably many reasons why a fresh install of 11.4 + updates fails completely...If an update is performed during non-automated install, there is a change in the PGP sig, a situation that install most often does not have provision for. Install was then restarted and the PGP update sig was imported o.k The next problems are centred around the main update repo and NO update is possible from anything below the URL's in screen shots. I think there may be an issue with the total length of the file's URL which becomes excessive but this is not the reason for a complete failure of performing any online update for 11.4 on a fresh install Attached are screen shots from failed updates and the URL response in FF and Y2logs 11.4 main update repo seems not to exist what-so-ever even for an established 11.4 installation -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c12 --- Comment #12 from Scott Couston 2012-05-22 03:30:26 UTC --- Created an attachment (id=491842) --> (http://bugzilla.novell.com/attachment.cgi?id=491842) screen shot URL in FF -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c14 --- Comment #14 from Scott Couston 2012-05-22 03:31:29 UTC --- Created an attachment (id=491844) --> (http://bugzilla.novell.com/attachment.cgi?id=491844) screen shot URL in FF -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c16 --- Comment #16 from Scott Couston 2012-05-22 03:40:40 UTC --- Created an attachment (id=491846) --> (http://bugzilla.novell.com/attachment.cgi?id=491846) screen shot URL in FF -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c17 --- Comment #17 from Scott Couston 2012-05-22 03:52:30 UTC --- I understand that this bug was closed before on the advise that the update server was not online. Weeks later NO update is possible for 11.4 X64. I am still of the opinion that retrospective changes to .DRPM file formats has created enormous issues for update repo's - I am sure there was a valid reason for the retrospective change rather than to have new versions only use .DRPM I still feel that at this late date that the change should be backed out and original update reinstated, however this too may take an inordinate period of time to recompile back to .RPM Detailed log files attached...This test install will remain valid for the next 3 weeks or so however, on an existing 11.4 X64 which also has more log file data or different log type request, will remain permanently available. Can we please fix this mess out - It hurts opensuse a great deal as there is much chatter about changes to .DRPM that is not very nice, out there -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c19 --- Comment #19 from Marcus Meissner 2012-05-22 15:44:01 UTC --- this is the name of the repository, not the URL itself (it just looks like a url) I looked through the logfiles yo attached and everything looks fine. can you run in a terminal as root zypper patch and capture its output? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c21 --- Comment #21 from Scott Couston 2012-05-25 02:21:47 UTC --- Created an attachment (id=492412) --> (http://bugzilla.novell.com/attachment.cgi?id=492412) output of requested - Please request ANY other audit logs that may help -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c23 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Critical |Major --- Comment #23 from Scott Couston 2012-05-25 05:04:14 UTC --- I have solved my problem with the 11.4 X_64 Main Update Repo. The problem has nothing to do with file/browsing permissions that are littered in vast quantities in the audit logs. The issue is that the file itself by-nature (.DRPM) fails an integrity check by ALG Engines. IF the user has File Integrity Control turned ON in routers or UTM devices, this is what happens The .DRPM file type of the file's downloaded by update, cannot be verified via MIME and cannot see it as an RPM - file type. For example Files with a file extension that does not match the file type can be blocked, for example an executable file (.exe) named 'image.gif' The previous .RPM file had no such problem as its MIME file type could be identified and matched against content. Any user that has ALG's running in realtime, to protect against all Virus/Spyware/Malicious type files like .core .so .csh .ksh .kdelnk who's MIME can audit the contents match the file extension type will all have problems. My UTM Hardware looks at every single file inbound,internal,outbound can easily find a .RPM file IS really a 'Red Hat Package Manager' - the file is passed without interference. After our new .DRPM file' gets to MIME interrogation it fails file types and halts the download o some but not others..AND THATS THE KICKER...why some ARE O.K AND OTHERS not OK -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=760457 https://bugzilla.novell.com/show_bug.cgi?id=760457#c25 Scott Couston changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Normal --- Comment #25 from Scott Couston 2012-06-01 00:38:30 UTC --- The .DRPM file integrity from the update repos cannot be verified against its MIME. Any user that has file integrity checks turned on will come across this problem. Yes the problem goes away if file integrity is turned off, however this is far from ideal. Its bad enough to depend on self signed PGPs however I understand the implications from the open software ethos. Data security is a growing monster with cloud based apps and cloud based storage and data security itself is becoming the new mandate. The other wider issue is why we continue to use HTTP traffic to move such large amounts of updates. The Nvida repo is about the only repo that uses FTP and I think all repos need to follow. I'll downgrade this problem as there is a work around to turn file integrity checking off, however I think we to lead in the subject of file integrity rather than follow. A huge benefit that Linux has in its almost Virus proof nature is our trump card together with perfect seamless limited user access with other file security flags; a huge asset but we need to get the file integrity against its MIME working perfectly -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.