I have tested both the 14.04 and 14.10 packages [1], and they work
great.
Splendid work, Chris!
-- [1]
http://archive.ubuntu.com/ubuntu/pool/universe/n/numactl/numactl_2.0.9~rc5-1ubuntu3.14.04.1_amd64.deb
Public bug reported:
numactl sometimes crashes when enumerating hardware:
root@node1:~# numactl --hardware
available: 648 nodes (0-647)
Segmentation fault
Further analysis shows that libnuma is using an uninitialised pointer,
which value depends on program layout. When layout is sufficiently
A CVE hasn't been assigned.
Presumably an attacker could manipulate the environment before an
application's libnuma call to have the uninitialised pointer point to
information in memory they'd like to extract, or cause a denial.
If an application that gained privileges (capabilities, setuid etc)
I've attached the debdiff with the fix.
** Patch added: debdiff with upstream fix
https://bugs.launchpad.net/ubuntu/+source/numactl/+bug/1441388/+attachment/4369005/+files/numactl_2.0.9%7Erc5-1ubuntu4.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server
This bug is still at large in Ubuntu 9.10, as observed on the desktop
x86-64 variant.
This may not be reproducible with 'static' configurations where the
automount tables are configured in files, but when they are specified in
nsswitch.conf as 'automount: ldap', this fails to initialise -
I can confirm this works as expected with the updated dhcpd3-common and
-client packages from Jonathan's PPA - the DHCP lease now has the 'ntp-
servers' option [1], consequently NTP has picked it up [2].
What else do we need to move this to the next step?
--- [1]
$ cat
Re-testing this situation on jaunty alpha 6 in an enterprise environment
with a Microsoft DHCP server, it's still not addressed.
The situation is therefore, one of:
- NTP syncs to ntp.ubuntu.com and silently maintains a constant offset from
our local timeserver
- NTP tries to sync to
Hi Chuck,
I tested your PPA's 'ipmitool_1.8.8-3.1ubuntu1~ppa1_amd64.deb' package
on intrepid 8.10 amd64, and found that when I enter SOL mode [1], no
further input is accepted.
The same test with ipmitool 1.8.9-1 (in the repos) works fine. Let me
know for further testing...
--- [1]
ipmitool -A
Problem is that SSH performance is still 10-30x slower with encryption.
On a 3.6GHz Intel Penryn with plenty of memory bandwidth [1], we see
around 67MB/s - 109MB/s [2]. Moving from 'secret' aes-128-cbc (the
default) to 'top-secret' aes-256-cbc (the most secure) is almost free.
Moving from MD5
This is the 'none' cipher patch:
http://www.psc.edu/networking/projects/hpn-ssh/openssh5.1-dynwindow_noneswitch.diff.gz
(from http://www.psc.edu/networking/projects/hpn-ssh/)
Since security is so critical, perhaps we should defer judgement to the
OpenSSH mailing lists?
--
[rfe] sshd ought to
Indeed it is true - we don't need 'default ntp-servers xyz' in
/etc/dhcp3/dhclient.conf, since the defaults in /etc/ntp.conf will be
used, as /etc/ntp.conf.dhcp won't be created. That's half the changes
then...
--
Request ntp-servers by default
https://bugs.launchpad.net/bugs/74164
You received
Incidentally, we should be requesting 'nis-servers' too, in case that
needs to be configured for the environment, eg where on a different
network segment, thus broadcasting for it won't find it.
--
Request ntp-servers by default
https://bugs.launchpad.net/bugs/74164
You received this bug
The fix for this, and obvious intended behaviour is:
- add 'ntp-servers' to the 'request' directive in /etc/dhcpd3/dhclient.conf
- add 'default ntp-servers 91.189.94.4' (ntp.ubuntu.com) to
/etc/dhcpd3/dhclient.conf
I confirm that where the DHCP server doesn't pass the 'ntp-servers'
option,
13 matches
Mail list logo
