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
http://archive.ubuntu.com/ubuntu/pool/universe/n/numactl/numactl_2.0.9~rc5-1ubuntu3.14.10.1
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 T
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)
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
dif
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 -
restarti
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 /var/lib/dhcp3/dhclient.et
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 ntp.ubuntu
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
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 su
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 has
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 notifica
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 t
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, the
13 matches
Mail list logo