Yum Update error: initscripts

D

demz

Verified User
Joined
Sep 7, 2006
Messages
69
Location
Holland, Den Haag
Hello,

A few weeks ago yum came up with mayor bunch of updates 100 or so even though i manually do yum update every day on the servers....
Kinda strange i felt, anyway installed good and no harm was done!

Since a few weeks i have this error on an yum update:

[root@dexter ~]# yum update
Setting up Update Process
Setting up repositories
update 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 35 kB 00:00
update : ################################################## 128/128
Added 1 new packages, deleted 0 old in 0.33 seconds
Excluding Packages in global exclude list
Finished
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package initscripts.i386 0:7.93.29.EL-1.centos4 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
initscripts i386 7.93.29.EL-1.centos4 base 1.1 M

Transaction Summary
=============================================================================
Install 0 Package(s)
Update 1 Package(s)
Remove 0 Package(s)
Total download size: 1.1 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : initscripts [1/2]warning: /etc/rc.d/init.d/functions saved as /etc/rc.d/init.d/functions.rpmsave
Updating : initscripts [1/2]warning: /etc/rc.d/init.d/netfs saved as /etc/rc.d/init.d/netfs.rpmsave
Updating : initscripts ######################### [1/2]
error: unpacking of archive failed on file /etc/rc.d/rc.local: cpio: rename

Updated: initscripts.i386 0:7.93.29.EL-1.centos4
Complete!

It seems complete but it isn't! every time when i do yum update it comes over and over again..

Someone has an idea to solve this?
 
It might be ( im not saying it is ) a permission problem.
When ik type ls -al i get this
Code: 
[root@1337h4ckb0x ~]# ls -al /etc/rc.d/rc.local
-rwxr-xr-x  1 root root 220 Jun 23  2003 /etc/rc.d/rc.local
[root@1337h4ckb0x ~]#
 
Thanks for the hint~!

I heb het probleem nu, got the problem!

I could not change the permissions of rc.local to 755 (like yours) well
from my shellkiddie times i remembered what we did with loser admins :)

CHATTR!!!

chattr -i rc.local and chmod 755 it and then yum update and it worked!

Thanks, bedankt!
 
You might want to look into why you had to use chattr. The only time I have had to do that is when a hacker got in and he chattr some files. Look hard. You may have been compromised.
 
at first i would say, your could be right, BUT on the other hand..

* I run chkrootkit and rkhunter every night with email report every morning, nothing strange...

* I have apf + bfd, load is 0.01 0.05 0.00 and netstat monitor doesn't give anything strange at all, nmap turns out nothing....

No strange procceses... or big traffics...

Theres nothing in rc.local exept an touch /var/lock/subsys/local an normal scriptkiddie rk would start up his services there...

I update with yum every day with hand on all servers :)
And i update all services with the script from @how@ so i always have the latest versions.

I just ran all the tests with hand because you made me paranoia :)

And nothing came out! Or this is an real l33t guy with an special reason to attack me or this is the most 0day exploit/rk ever.... and then i need to find it on my server so i can sell it :)

With other words: i can go to sleep now without worries :)
 
it seems i forgot i also used the little secure-it script from h4h; lol

That secures and sets rights on important files; whehe how para can i get :)
 
Maybe one of your security scripts changed the file attributes so that a script kiddie could not change the files.
 
You must log in or register to reply here.
Back
Top