SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
- download all that files, and in its directory run "pkgtool", and "install packages from current directory".
looks like instead this i must be do "upgradepkg *.txz" , but now is too late - i have in packages list all that glibc x86_64_9 files, and also previous version x86_64-7 packages too.
try do "upgradepkg *.txz" now and get,as i can expect,
what i must do? do newer package automatically replace older? or i must manually remove via pkgtool -> remove, all new packages, and do upgradepkg ?
or what?
Also interested in - after that glibc upgrade i must restart server, or new packages start working ok without restart?
Also interesting about multilibs - after glibc upgrade i must build multilibs again?
- download all that files, and in its directory run "pkgtool", and "install packages from current directory".
looks like instead this i must be do "upgradepkg *.txz" , but now is too late - i have in packages list all that glibc x86_64_9 files, and also previous version x86_64-7 packages too.
try do "upgradepkg *.txz" now and get,as i can expect,
what i must do? do newer package automatically replace older? or i must manually remove via pkgtool -> remove, all new packages, and do upgradepkg ?
As you found, you can actually install the same package but different versions side-by-side. If the files are named the same, installpkg will clobber the existing files with the ones from the package you invoked pkgtool (installpkg) with. Normally, when you removepkg any package that has the same files found in other packages, removepkg will not touch them. The only grey area here is what any doinst.sh script has done. You can removepkg the older package, but with a package like glibc, you might want to have a fail-safe plan in case the system stops working. But in general, the thing to do is removepkg the older package, and not worry about upgradepkg --reinstall or trying to remove the newly installed package.
Note that I do not remember having to deal the glibc this way, so again, have a plan to handle anything that might happen.
Quote:
Originally Posted by WiseDraco
Also interested in - after that glibc upgrade i must restart server, or new packages start working ok without restart?
Considering the type of vulnerability, I decided that it is easier just to reboot my systems. You don't always need to reboot, even for libc, but this had local and remote execution possibilities, and it is easier to flush old copies of libc with a reboot. Again plan accordingly.
Quote:
Originally Posted by WiseDraco
Also interesting about multilibs - after glibc upgrade i must build multilibs again?
I have never used multilib, so I do not know the steps, but your multilib needs an update too.
Considering the type of vulnerability, I decided that it is easier just to reboot my systems. You don't always need to reboot, even for libc, but this had local and remote execution possibilities, and it is easier to flush old copies of libc with a reboot. Again plan accordingly.
I listed processes that had held open the previous version of libc
Code:
lsof | egrep 'DEL.*(libc)' | sort
Then went and killed the user space ones.
For some of the system stuff you can use the init scripts - example:
Code:
cd /etc/rc.d
./rc.sshd restart
./rc.httpd restart
./rc.bind restart
./rc.syslogd restart
For some processes you can just cause them to reload:
Code:
killall -HUP agetty
For myself I figured that restarting udevd wasn't important and didn't want to risk even trying on a remote server, as from experience you can't really restart it without some side effects. Please correct me if I'm wrong!
I listed processes that had held open the previous version of libc
Code:
lsof | egrep 'DEL.*(libc)' | sort
Then went and killed the user space ones.
For some of the system stuff you can use the init scripts - example:
Code:
cd /etc/rc.d
./rc.sshd restart
./rc.httpd restart
./rc.bind restart
./rc.syslogd restart
For some processes you can just cause them to reload:
Code:
killall -HUP agetty
For myself I figured that restarting udevd wasn't important and didn't want to risk even trying on a remote server, as from experience you can't really restart it without some side effects. Please correct me if I'm wrong!
Ah thanks for refreshing my memory on how to handle it. I checked lsof previously, but decided libc touched enough services, I didn't want to audit each one. But I went ahead and checked udevd with objdump -T and found no gethostbyname symbols. So I think we could get by without a restart, but of course I can't know everyone's system.
Ah thanks for refreshing my memory on how to handle it. I checked lsof previously, but decided libc touched enough services, I didn't want to audit each one. But I went ahead and checked udevd with objdump -T and found no gethostbyname symbols. So I think we could get by without a restart, but of course I can't know everyone's system.
OK good to know - I didn't expect udev to do host lookups but did not check.
I realised that killall -HUP is not useful -- the reason agetty was restarted was because it died in response to -HUP, and init restarted it.
I confused myself - -HUP causes some processes to reload their configs (inetd is an example) if they are programmed to respond to -HUP in this way: they don't restart the process, so -HUP would never be useful in this situation.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.