Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Server: Red Hat Enterprise Linux Server release 5.9 (Tikanga)
I came to know that Linux GNU C Library (glibc) versions prior to 2.18 are vulnerable to remote code execution via a vulnerability in the gethostbyname function. Exploitation of this vulnerability may allow a remote attacker to take control of an affected system.
Linux distributions employing glibc-2.18 and later are not affected. This vulnerability is similar to similar to ShellShock and Heartbleed that we saw recently.
I see, the patch is available here: https://access.redhat.com/security/cve/CVE-2015-0235 (RedHat) or http://www.ubuntu.com/usn/usn-2485-1/ (Ubuntu).
I'm planning to patch our Linux systems (it would require reboot) and wanted to check on few items:
Has anybody tried to patch their systems to solve this vulnerablity and what's the impact of the patch across Linux platforms/applications running?
I don't think I will be fine if I just upgrade glibc binaries via yum upgrade.
Where can I find a step by step guide to fix this issue.
One can see more info about this here: https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability
1) The patched version of glibc is for sure already running in thousands of machines. There shouldn't be other noticeable impacts than getting the vulnerability solved
2) Yes, it is enough if you update glibc via yum and reboot afterwards
3) You won't need a step by step guide, as updating is really straight-forward. Just update glibc via package manager such as yum and reboot.
In theory, it is also possible not to reboot by only restarting all the applications that are linked to glibc. But in practice, it is so commonly used library that it is a lot easier to just reboot the whole machine.
As shane mentioned: https://serverfault.com/questions/663499/linux-glibc-versions-2-18-and-older-vulnerability
Has anybody tried to patch their systems to solve this vulnerability and what's the impact of the patch across Linux platforms/applications running?
Running applications will stay using the old version until they're restarted - just installing the patch should not have any impact. This is why it's probably best to just flat-out-reboot.
I don't think I will be fine if I just upgrade glibc binaries via yum upgrade.
Right - doing just the upgrade will leave your running applications on vulnerable code.
Where can I find a step by step guide to fix this issue.
Right here, why not:
yum update "glibc*"
reboot
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I made a mistake during the installation of Debian 11. My plan was to run Debian next to Win10 by using Grub2 but installed Debian high secure LVM which overwrote my notebook's complete Harddisk. I am completely new to Linux so as you can imagine I struggle hard because I only have a "DOS-style-Terminal". The Debian 11 .iso ist only 3xx mb large and I wonder if i am able to install Gnome from the given Terminal. Some sources mentioned Gnome could be part of the .iso .Is it true? Do I have a chance to process? If not I concidered to add a folder on the bootable USB stick, add something like "gnome.deb" and try to progress this way. I dont have internet in my Asus Vivobook model M712D because of missing"RTW88......" which makes my situation even worse but can access the internet by my Smartphone. In the end I want to install vscode to progress at www.freecodecamp.org using Debian instead of Kali for advanced Linux learning and future operations. I am sure this is a topic to discuss, I cant imagine I am the only one struggling on this issue. Many Windows user gets prevented from using linux by this issue .
The small size of the image indicates that you probably used the Network Install image. This minimal image does not feature desktop environments. Your options are:
Download an image that features a desktop environment (complete installation image, see here) and reinstall Debian using this image.
Install the desktop environment yourself. To do that, you could try sudo apt-get update && sudo apt-get install task-gnome-desktop. This, however requires an internet connection.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I need to install a package on a system without internet access (the package contains a driver for network card).
System A has internet connection and runs Ubuntu 14; System B has no internet connection and runs Ubuntu 16.
How can I download all dependencies recursively with the correct version on system A, that could be next installed on system B?
I would suggest that you run a docker container (or some type of virtualization) with Ubuntu 16.04 on System A. After that, you can update the packages index (apt update) then install the desired packages on that system. Finally, you may copy the packages index from /var/lib/apt, and the packages themselves from /var/cache/apt/archives to System B.
It's a good practice to restrict hosts from internet access. However, as a patch management solution, you should setup a local mirror - this will centralize your patching needs for the entire organization. It's not just limited to ubuntu but you could host multiple linux distro mirrors. The only thing you really need is a large capacity disk, maybe mirror it for some non-critical resiliency. This will also cut-back on a multi-server environment using bandwidth, limiting the bandwidth to a single host pulling updates to it's mirror one-time. Just make sure you have a process or script to run to regularly check for updates. That way your hosts are ready for patching when you need it, assuming you stay on top of emerging threats and vulnerability management for various *Nix platforms.
I'm not a huge fan of reinventing the wheel so.. here's a couple how-to references.
How-to: Setup a local Ubuntu Aptitude Repo (Can setup to mirror Ubuntu 14,15,16 to support all your linux hosts.)
How-to: Set a local CentOS YUM Repo (just incase you have some RH based servers)
What you're going to have to do afterwards is change your /etc/apt/sources.list to point to your new internal repository for aptitude repos. You can just copy the lines existing there, change the server domain name to your local server. Then you don't need any of your linux hosts to communicate to any hosts outside of your network, the one server pulling from the mirrors can. It will definitely help you refine your security needs.
For RHEL based or yum, it's configured in /etc/yum.repos.d/{reponame}.repo
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I need to create a reliable and accurate synchronization between two CentOS 6 machines connected through a direct Ethernet connection.
I've seen that on Linux several implementation of the IEEE 1588 Precision Time Protocol (PTP) exist:
PTPd:
Apparently, this is the original implentation
Source code available on GitHub (appparently, still maintained almost unmaintained)
PTPd2:
A new version meant to supersede the previous implementation
Apparently unmaintained
For CentOS 6, available only in the EPEL repositories
PTPv2d:
A further implementation
Unmaintained as well
linuxptp:
A specific implementation for Linux
Maintained
Available on the CentOS repositories
Suggested by the RedHat documentation for both RedHat 6 and RedHat 7
My questions follow:
Why does the RedHat documentation suggest the use of linuxptp for RedHat 6 (based on Linux kernel 2.6) despite the linuxptp documentation says that a Linux kernel version 3.0 or newer is needed ?
Which are differences between PTPd2 and Linuxptp in terms of reliability and timing accuracy ?
Which one should I prefer on CentOS 6 and on CentOS 7, respectively ?
Why either PTPd2 and Linuxptp do not synchronize immediately and often need me to start/stop the service several times or manually change system time through date to make the machine synchronize ?
Linuxptp works on RH6 thanks to RedHat backporting PTP support, as explained here. Indeed, it is the only choice, as the other packages have not been maintained.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I know that apt-get is meant to be a packaging manager for Debian. But I'd like to learn if this software can be also ported to different operating systems, especially to Slackware.
I am the author of Slax, a Slackware-based operating system, so I know lots of the internals of a working OS, library dependencies, and so on. From my point of view, installing a debian package to Slackware or other distribution is fairly possible if both the distros share similar libraries, which most Linuxes do nowadays. Slackware, despite it's focus on stability, is usually using recent libraries as like Debian.
As far as I understand apt, it's just an application which tracks dependencies and has a list of mirrors from which to download packages. Unpacking the deb packages is a matter of
ar -x
Most init scripts will be the same if the Sys-V init style is supported. Some of the Debian packages may not work out of the box, especially those which are deeply system-related, like udev for example, but majority of the APPLICATIONS should install and work OK on Slackware in my opinion. I tried Google's official Chrome Browser package for Debian and it works just fine on Slackware.
Are there any drawbacks in porting apt-get to Slackware or other Linux? Did anybody attempt to port it already? Thank you
The package slapt-get is the Slackware implementations of apt-get.
slapt-get install whatever-package
Any way you should be able to compile it on any OS. Of course you might have to do some small changes to the source if the repos structure and files to download are very different.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I am a bit confused by the fact that although I installed RHEL 5.1 from DVD (RedHat/5.1.x86_64), when I issue command:
cat /etc/redhat-release
I got:
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
What does this mean? is this to be the release version or kernel version? Is there another way to confirm the real version of RHEL?
I am asking this question because there will be certain applications that would depend on this.
Many thanks in advance.
Avoid /etc/*release* files and run this command instead, it is far more reliable and gives more details:
rpm -qia '*release*'
I assume that you've run yum upgrade. That will in general update you to the newest minor release.
Your main resources for determining the version are /etc/redhat_release and lsb_release -a
That's the RHEL release version.
You can see the kernel version by typing uname -r. It'll be 2.6.something.
That is the release version of RHEL, or at least the release of RHEL from which the package supplying /etc/redhat-release was installed. A file like that is probably the closest you can come; you could also look at /etc/lsb-release.
It is theoretically possible to have packages installed from a mix of versions (e.g. upgrading part of the system to 5.5 while leaving other parts at 5.4), so if you depend on the versions of specific components you will need to check for those individually.