Hello guys,
When I issue the command yum update I get the following dependencies problems: (I have the following repos enabled: atrpms, base, dag, dries, fedora extras, flash, freshrpms, gstreamer, jpackage, kde-redhat, livna and newrpms)
yum update:
Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for arts to pack into transaction set. arts-1.4.2-1.2.fc4.kde.i3 100% |=========================| 21 kB 00:00 ---> Package arts.i386 8:1.4.2-1.2.fc4.kde set to be updated ---> Downloading header for libsndfile to pack into transaction set. libsndfile-1.0.11-6.rhfc4 100% |=========================| 3.5 kB 00:00 ---> Package libsndfile.i386 0:1.0.11-6.rhfc4.at set to be updated ---> Downloading header for k3b-extras to pack into transaction set. k3b-extras-0.12.3-1.1.fc4 100% |=========================| 11 kB 00:00 ---> Package k3b-extras.i386 0:0.12.3-1.1.fc4.kde set to be updated ---> Downloading header for k3b to pack into transaction set. k3b-0.12.3-1.1.fc4.kde.i3 100% |=========================| 35 kB 00:00 ---> Package k3b.i386 0:0.12.3-1.1.fc4.kde set to be updated ---> Downloading header for samba-common to pack into transaction set. samba-common-3.0.14a-2.1. 100% |=========================| 39 kB 00:00 ---> Package samba-common.i386 0:3.0.14a-2.1.fc4.kde set to be updated ---> Downloading header for wine to pack into transaction set. wine-0.20050725-1.rhfc4.n 100% |=========================| 36 kB 00:00 ---> Package wine.i386 0:0.20050725-1.rhfc4.nr set to be updated ---> Downloading header for kdemultimedia to pack into transaction set. kdemultimedia-3.4.2-1.0.f 100% |=========================| 190 kB 00:01 ---> Package kdemultimedia.i386 6:3.4.2-1.0.fc4.kde set to be updated ---> Downloading header for mjpegtools-libs to pack into transaction set. mjpegtools-libs-1.8.0-0.l 100% |=========================| 7.3 kB 00:00 ---> Package mjpegtools-libs.i386 0:1.8.0-0.lvn.1.4 set to be updated ---> Downloading header for ImageMagick to pack into transaction set. ImageMagick-6.2.3.0-0.1.f 100% |=========================| 78 kB 00:00 ---> Package ImageMagick.i386 0:6.2.3.0-0.1.fc4.kde set to be updated ---> Downloading header for mplayerplug-in to pack into transaction set. mplayerplug-in-3.11-22.rh 100% |=========================| 8.5 kB 00:00 ---> Package mplayerplug-in.i386 0:3.11-22.rhfc4.at set to be updated ---> Downloading header for pyxdg to pack into transaction set. pyxdg-0.15-1.rhfc4.nr.i38 100% |=========================| 5.0 kB 00:00 ---> Package pyxdg.i386 0:0.15-1.rhfc4.nr set to be updated ---> Downloading header for samba-client to pack into transaction set. samba-client-3.0.14a-2.1. 100% |=========================| 35 kB 00:00 ---> Package samba-client.i386 0:3.0.14a-2.1.fc4.kde set to be updated ---> Downloading header for qt to pack into transaction set. qt-3.3.4-17.4.fc4.kde.i38 100% |=========================| 19 kB 00:00 ---> Package qt.i386 1:3.3.4-17.4.fc4.kde set to be updated ---> Downloading header for y4mscaler to pack into transaction set. y4mscaler-8.1-0.lvn.4.4.i 100% |=========================| 3.3 kB 00:00 ---> Package y4mscaler.i386 0:8.1-0.lvn.4.4 set to be updated ---> Downloading header for mjpegtools to pack into transaction set. mjpegtools-1.8.0-0.lvn.1. 100% |=========================| 17 kB 00:00 ---> Package mjpegtools.i386 0:1.8.0-0.lvn.1.4 set to be updated ---> Downloading header for kdelibs to pack into transaction set. kdelibs-3.4.2-1.2.fc4.kde 100% |=========================| 683 kB 00:03 ---> Package kdelibs.i386 6:3.4.2-1.2.fc4.kde set to be updated ---> Downloading header for ImageMagick-c++ to pack into transaction set. ImageMagick-c%2B%2B-6.2.3 100% |=========================| 12 kB 00:00 ---> Package ImageMagick-c++.i386 0:6.2.3.0-0.1.fc4.kde set to be updated ---> Downloading header for perl-GDGraph to pack into transaction set. perl-GDGraph-1.43-6.rhfc4 100% |=========================| 5.8 kB 00:00 ---> Package perl-GDGraph.noarch 0:1.43-6.rhfc4.at set to be updated ---> Downloading header for kdebase to pack into transaction set. kdebase-3.4.2-1.5.fc4.kde 100% |=========================| 677 kB 00:05 ---> Package kdebase.i386 6:3.4.2-1.5.fc4.kde set to be updated ---> Downloading header for dbus-devel to pack into transaction set. dbus-devel-0.33-3.1.fc4.k 100% |=========================| 15 kB 00:00 ---> Package dbus-devel.i386 0:0.33-3.1.fc4.kde set to be updated --> Running transaction check --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: audac ity --> Processing Dependency: libsndfile.so.1 for package: alsaplayer --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: libsn dfile --> Processing Dependency: libsndfile.so.1 for package: ecasound --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: k3b --> Processing Dependency: libdbus-qt-1.so.1 for package: k3b-extras --> Processing Dependency: libsndfile.so.1 for package: audacity --> Processing Dependency: libsndfile.so.1 for package: libsndfile --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: libgi g --> Processing Dependency: libmjpegutils-1.6.so.0 for package: transcode --> Processing Dependency: libsndfile.so.1 for package: ardour --> Processing Dependency: libHalf.so.2 for package: kdebase --> Processing Dependency: libdbus-qt-1.so.1 for package: k3b --> Processing Dependency: libImath.so.2 for package: kdebase --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: libsa mplerate --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: ardou r --> Processing Dependency: libsndfile.so.1 for package: muse --> Processing Dependency: libjasper-1.701.so.1 for package: ImageMagick --> Processing Dependency: libsndfile1 = 1.0.11 for package: libsndfile --> Processing Dependency: libsndfile.so.1 for package: libsamplerate --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: ecaso und --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: muse --> Processing Dependency: libIex.so.2 for package: kdebase --> Processing Dependency: libjasper-1.701.so.1 for package: kdelibs --> Processing Dependency: libsndfile.so.1 for package: libgig --> Processing Dependency: libtunepimp.so.2 for package: kdemultimedia --> Processing Dependency: libsndfile.so.1 for package: k3b --> Processing Dependency: libdns_sd.so.1 for package: kdelibs --> Processing Dependency: dbus-qt = 0.33-3.1.fc4.kde for package: dbus-devel --> Processing Dependency: libIlmImf.so.2 for package: kdebase --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: alsap layer --> Processing Dependency: mplayer-skin-mini for package: mplayerplug-in --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for mplayer-skin-mini to pack into transaction set. mplayer-skin-mini-0.1-11. 100% |=========================| 3.3 kB 00:00 ---> Package mplayer-skin-mini.noarch 4:0.1-11.1.at set to be updated ---> Downloading header for mDNSResponder to pack into transaction set. mDNSResponder-98-0.2.fc4. 100% |=========================| 3.7 kB 00:00 ---> Package mDNSResponder.i386 0:98-0.2.fc4 set to be updated ---> Downloading header for dbus-qt to pack into transaction set. dbus-qt-0.33-3.1.fc4.kde. 100% |=========================| 11 kB 00:00 ---> Package dbus-qt.i386 0:0.33-3.1.fc4.kde set to be updated ---> Downloading header for libtunepimp to pack into transaction set. libtunepimp-0.3.0-0.1.fc4 100% |=========================| 4.3 kB 00:00 ---> Package libtunepimp.i386 0:0.3.0-0.1.fc4 set to be updated ---> Downloading header for libsndfile1 to pack into transaction set. libsndfile1-1.0.11-6.rhfc 100% |=========================| 2.6 kB 00:00 ---> Package libsndfile1.i386 0:1.0.11-6.rhfc4.at set to be updated ---> Downloading header for jasper to pack into transaction set. jasper-1.701.0-4.i386.rpm 100% |=========================| 4.0 kB 00:00 ---> Package jasper.i386 0:1.701.0-4 set to be updated ---> Downloading header for OpenEXR to pack into transaction set. OpenEXR-1.2.2-5.fc4.i386. 100% |=========================| 6.0 kB 00:00 ---> Package OpenEXR.i386 0:1.2.2-5.fc4 set to be updated --> Running transaction check --> Processing Dependency: libmjpegutils-1.6.so.0 for package: transcode --> Finished Dependency Resolution Error: Missing Dependency: libmjpegutils-1.6.so.0 is needed by package transcode
Do I need any extra repos to resolve this?
Thanks
Mirco
Mirco Scara kirjoitti viestissään (lähetysaika torstai, 29. syyskuuta 2005 11:40):
--> Processing Dependency: libmjpegutils-1.6.so.0 for package: transcode --> Finished Dependency Resolution Error: Missing Dependency: libmjpegutils-1.6.so.0 is needed by package transcode
Do I need any extra repos to resolve this?
Most likely you should _disable_ some repos to resolve the conflict.
After downloading and installing gnome-pkgview and gnome-common (which pkgview needed) tripwire started complaining about a whole bunch of files that had suddenly changed checksums, and in many cases, the sizes of the files as well, including tripwire itself. Did I just get zapped by something nasty, or does tripwire sometimes get a little confused?
On Wednesday 05 October 2005 17:35, Bill Perkins wrote:
After downloading and installing gnome-pkgview and gnome-common (which pkgview needed) tripwire started complaining about a whole bunch of files that had suddenly changed checksums, and in many cases, the sizes of the files as well, including tripwire itself. Did I just get zapped by something nasty, or does tripwire sometimes get a little confused?
--
---- "The two most common things in the | Bill Perkins universe are Hydrogen and Stupidity." | perk@iag.net
| programmer-at-large F. Zappa | ALL assembly languages done here.
Probably neither. Most likely these files were upgraded during the install and the tripwire database needs to be updated.
On Wed, 2005-10-05 at 17:35, Bill Perkins wrote:
After downloading and installing gnome-pkgview and gnome-common (which pkgview needed) tripwire started complaining about a whole bunch of files that had suddenly changed checksums, and in many cases, the sizes of the files as well, including tripwire itself. Did I just get zapped by something nasty, or does tripwire sometimes get a little confused?
Where the files all part of gnome-common? Did you update tripwire after you upgraded gnome-common? When did tripwire report a violation?
Three possibilities. One, tripwire ran at it's usual time and reported the changed files which you upgraded.
Two, if you updated tripwire after doing the upgraded prelink probably ran later than night and modified the updated files you installed via gnome-common. Tripwire then reported the differences.
Third, if neither one or two are possibilities then you need to look at the particular files being reported. You might have been hacked.
On Wednesday 05 October 2005 19:27, Scot L. Harris wrote:
On Wed, 2005-10-05 at 17:35, Bill Perkins wrote:
Two, if you updated tripwire after doing the upgraded prelink probably ran later than night and modified the updated files you installed via gnome-common. Tripwire then reported the differences.
Thanks for reminding me. I haven't run prelink for some time, and I run it manually.
Scot L. Harris wrote:
On Wed, 2005-10-05 at 17:35, Bill Perkins wrote:
After downloading and installing gnome-pkgview and gnome-common (which pkgview needed) tripwire started complaining about a whole bunch of files that had suddenly changed checksums, and in many cases, the sizes of the files as well, including tripwire itself. Did I just get zapped by something nasty, or does tripwire sometimes get a little confused?
Where the files all part of gnome-common? Did you update tripwire after you upgraded gnome-common? When did tripwire report a violation?
No, very few of them were part of gnome-common
Three possibilities. One, tripwire ran at it's usual time and reported the changed files which you upgraded.
It did, with a whole bunch more.
Two, if you updated tripwire after doing the upgraded prelink probably ran later than night and modified the updated files you installed via gnome-common. Tripwire then reported the differences.
Haven't upgraded tripwire since installing it. Looks like the tripwire rpm gets compromised as well, through yum (yum erase tripwire; yum install tripwire yields a different tripwire md5 each time. Very strange, different from the one on backup.)
Third, if neither one or two are possibilities then you need to look at the particular files being reported. You might have been hacked.
There is a ton of files, most of which have nothing to do with gnome-common or gnome-pkgview, both of which were installed just prior to this. I also added the livna repo (per instructions from some yum FAQ) just prior to this.
On Thu, 2005-10-06 at 00:43, Bill Perkins wrote:
Scot L. Harris wrote:
On Wed, 2005-10-05 at 17:35, Bill Perkins wrote:
After downloading and installing gnome-pkgview and gnome-common (which pkgview needed) tripwire started complaining about a whole bunch of files that had suddenly changed checksums, and in many cases, the sizes of the files as well, including tripwire itself. Did I just get zapped by something nasty, or does tripwire sometimes get a little confused?
Where the files all part of gnome-common? Did you update tripwire after you upgraded gnome-common? When did tripwire report a violation?
No, very few of them were part of gnome-common
Three possibilities. One, tripwire ran at it's usual time and reported the changed files which you upgraded.
It did, with a whole bunch more.
Two, if you updated tripwire after doing the upgraded prelink probably ran later than night and modified the updated files you installed via gnome-common. Tripwire then reported the differences.
Haven't upgraded tripwire since installing it. Looks like the tripwire rpm gets compromised as well, through yum (yum erase tripwire; yum install tripwire yields a different tripwire md5 each time. Very strange, different from the one on backup.)
Third, if neither one or two are possibilities then you need to look at the particular files being reported. You might have been hacked.
There is a ton of files, most of which have nothing to do with gnome-common or gnome-pkgview, both of which were installed just prior to this. I also added the livna repo (per instructions from some yum FAQ) just prior to this.
How long had tripwire been running prior to this event? Prelink caused me a fit once on a new system I had setup. The next morning it looked like everything had been compromised.
I believe you can use rpm to validate the files on your system. rpm is prelink aware. Check the verify option of rpm. If that shows things don't match up then you have a system that may have been compromised.
Because it is reporting huge numbers of files on your system I am thinking this is due to prelinking. I suspect that all the files reported are executables and not text config file.
Scot L. Harris wrote:
How long had tripwire been running prior to this event? Prelink caused me a fit once on a new system I had setup. The next morning it looked like everything had been compromised.
Since September or so.
I believe you can use rpm to validate the files on your system. rpm is prelink aware. Check the verify option of rpm. If that shows things don't match up then you have a system that may have been compromised.
I'll take a look into that. What is 'prelink'?
Because it is reporting huge numbers of files on your system I am thinking this is due to prelinking. I suspect that all the files reported are executables and not text config file.
Most are executables, some libraries as well (in /usr/lib, openoffice, a bunch of others).
On Thu, 2005-10-06 at 08:45, Bill Perkins wrote:
I believe you can use rpm to validate the files on your system. rpm is prelink aware. Check the verify option of rpm. If that shows things don't match up then you have a system that may have been compromised.
I'll take a look into that. What is 'prelink'?
Most are executables, some libraries as well (in /usr/lib, openoffice, a bunch of others).
Prelink is used to modify ELF shared libraries and ELF dynamiclly linked binaries to reduce startup time. Check out the man page for prelink to get more details.
The changes you describe are consistent with prelink.
On Thursday 06 October 2005 08:58, Scot L. Harris wrote:
On Thu, 2005-10-06 at 08:45, Bill Perkins wrote:
I believe you can use rpm to validate the files on your system. rpm is prelink aware. Check the verify option of rpm. If that shows things don't match up then you have a system that may have been compromised.
I'll take a look into that. What is 'prelink'?
Most are executables, some libraries as well (in /usr/lib, openoffice, a bunch of others).
Prelink is used to modify ELF shared libraries and ELF dynamiclly linked binaries to reduce startup time. Check out the man page for prelink to get more details.
The changes you describe are consistent with prelink.
You could try something like; --> rpm -vV -a > /root/rpm_verify Then try less the file /root/rpm_verify.
jludwig wrote:
On Thursday 06 October 2005 08:58, Scot L. Harris wrote:
On Thu, 2005-10-06 at 08:45, Bill Perkins wrote:
I believe you can use rpm to validate the files on your system. rpm is prelink aware. Check the verify option of rpm. If that shows things don't match up then you have a system that may have been compromised.
I'll take a look into that. What is 'prelink'?
Most are executables, some libraries as well (in /usr/lib, openoffice, a bunch of others).
Prelink is used to modify ELF shared libraries and ELF dynamiclly linked binaries to reduce startup time. Check out the man page for prelink to get more details.
The changes you describe are consistent with prelink.
Yes- after perusing the man page, that makes some sense. However, where did prelink get triggered from? I sure didn't run it.
You could try something like; --> rpm -vV -a > /root/rpm_verify Then try less the file /root/rpm_verify.
Cool! I've had it running for a few hours now (this is a 1GHz PIII of some sort, with 256M RAM, so it's not the fastest processor on the block), and the output looks reasonable so far. I've just switched to FC4 from Slackware, and I don't know all the ins and outs of rpm, yum, and up2date, so even though I've been using Linux for 10 years now, I'm still on a learning curve (which is why I jumped to Linux in the first place). Thanks for all the help, I'll let you know what I find.
On Thu, 2005-10-06 at 22:21, Bill Perkins wrote:
jludwig wrote:
On Thursday 06 October 2005 08:58, Scot L. Harris wrote:
Prelink is used to modify ELF shared libraries and ELF dynamiclly linked binaries to reduce startup time. Check out the man page for prelink to get more details.
The changes you describe are consistent with prelink.
Yes- after perusing the man page, that makes some sense. However, where did prelink get triggered from? I sure didn't run it.
Depends on how you run the system. By default there should be a cron job in /etc/cron.daily called prelink. If your system runs 24x7 it should run at least once a day.
You could try something like; --> rpm -vV -a > /root/rpm_verify Then try less the file /root/rpm_verify.
Cool! I've had it running for a few hours now (this is a 1GHz PIII of some sort, with 256M RAM, so it's not the fastest processor on the block), and the output looks reasonable so far. I've just switched to FC4 from Slackware, and I don't know all the ins and outs of rpm, yum, and up2date, so even though I've been using Linux for 10 years now, I'm still on a learning curve (which is why I jumped to Linux in the first place). Thanks for all the help, I'll let you know what I find.
It is a constant learning curve, always new things to learn. And usually just when you get a handle on one service it gets changed. :)
Scot L. Harris wrote:
On Thu, 2005-10-06 at 22:21, Bill Perkins wrote:
jludwig wrote:
On Thursday 06 October 2005 08:58, Scot L. Harris wrote:
Prelink is used to modify ELF shared libraries and ELF dynamiclly linked binaries to reduce startup time. Check out the man page for prelink to get more details.
The changes you describe are consistent with prelink.
Yes- after perusing the man page, that makes some sense. However, where did prelink get triggered from? I sure didn't run it.
Depends on how you run the system. By default there should be a cron job in /etc/cron.daily called prelink. If your system runs 24x7 it should run at least once a day.
Interesting. /var/log/prelink.log doesn't leave any timestamps; apparently, it's part of the base package, but for some reason, it hasn't made itself apparent (at least to tripwire) until now. For the most part, the system runs 24/7, with the occasional reboot into Slackware for an hour or two; had this system operating since beginning of September. Fedora has some interesting quirks, to say the least! Still easier to deal with than Microsoft :)
You could try something like; --> rpm -vV -a > /root/rpm_verify Then try less the file /root/rpm_verify.
Cool! I've had it running for a few hours now (this is a 1GHz PIII of some sort, with 256M RAM, so it's not the fastest processor on the block), and the output looks reasonable so far. I've just switched to FC4 from Slackware, and I don't know all the ins and outs of rpm, yum, and up2date, so even though I've been using Linux for 10 years now, I'm still on a learning curve (which is why I jumped to Linux in the first place). Thanks for all the help, I'll let you know what I find.
It is a constant learning curve, always new things to learn. And usually just when you get a handle on one service it gets changed. :)
Sounds like Microsoft ;)
-
bill perkins -
jludwig -
Markku Kolkka -
Mirco Scara -
Scot L. Harris