Mathias Gug wrote:
On Thu, Oct 22, 2009 at 08:24:46AM -, cwsupport wrote:
Resolv.conf did have two lines with nameserver entries for the two
entries that were moved to Bind9.
I can't reproduce this. Using a standard karmic system, installing the
bind9 package does
Resolv.conf did have two lines with nameserver entries for the two
entries that were moved to Bind9.
This configuration WORKS under Hardy Heron and AFAIK intrepid.
The problem is resolved via an entry in resolv.conf of 'nameserver
127.0.0.1'.
Before this is discounted though how come DIG still
Public bug reported:
Binary package hint: bind9
Ubuntu Karmic Koala 9.10 BETA
FULLY updated via apt-get dist-upgrade
bind9: 1:9.6.1.dfsg.P1-3
After bind9 is installed hostname resolution no longer occurs on programs such
as ping. However dig resolves successfully via the local server.
Bind9
Oops. I mean Hardy Heron 8.04.
--
Installing bind9 with forwarders causes loss of hostname resolution.
https://bugs.launchpad.net/bugs/456224
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bind9 in ubuntu.
--
Ubuntu-server-bugs mailing
This is *STILL* an issue in Karmic Koala 9.10 BETA.
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
https://bugs.launchpad.net/bugs/114505
You received this bug notification because you are a member of Ubuntu
Server Team, which is a bug
NOTE: The patch works for Karmic Koala as well.
--
ntp brought up before network is ready; fails not resolve any ip or host names;
ntp does not recover
https://bugs.launchpad.net/bugs/114505
You received this bug notification because you are a member of Ubuntu
Server Team, which is a bug
Here is a patch to /etc/init.d/ntp that will ensure that the NTP service
comes up and the hwclock is re-sync'd even if the panic-threshold would
normally stop ntpd from syncing.
This may not be applicable to everyone but I believe it should be the
default behaviour - maybe a switch could be
oops. re: the last patch.
I still believe that the option to set the date via ntpdate
automatically should be based on options in /etc/default and that merely
having the ntp package installed should not invoke functionality in a
mandatory manner without being able to easily switch off that
Here is a patch that works in conjunction with the previous patch.
If the ntp daemon is running already it is simply restarted (previous
patch includes syncing ntpdate and setting the hwclock in the init.d
script).
If the ntp daemon is not running already ntpdate-debian is called and
the hwclock
Hi,
Yes thats the whole problem! The no-association IDs is caused by ntpd
coming up too early - a restart fixes this.
What the fix does is PRIOR to S23ntp running ntpd will not be started
due to the if-up script - this means that subsequently when S23ntp runs
S15bind9 has already come up and
It will not affect them in any way at all. The ntpd will come up at the
right time as specified in rc2.d.
Resolution without local DNS will result in gethostbyname() going out to
an external DNS and this functionality will not be affected.
The fix is therefore transparent to most users (hence
Hi,
I disagree with this diagnosis..
S28NetworkManager is a red-herring. For a start Hardy doesnt have
this...Looking at the startup for Hardy:
S15bind9
S16openvpn
S16ssh
S17mysql-ndb-mgm
S17portmap
S18avahi-daemon
S18mysql-ndb
S19mysql
S20apmd
S20apport
S20cupsys
S20cyrus2.2
S20exim4
re tampering :) Know how you feel.
Because of this I feel it is better to fix the problem at source (pun
intended!) and have raised #288914 [
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/288914 ] to try to
prompt discussions. When I get a chance I will d/l the source and fix it
Hi,
Onno Benschop wrote:
On 25/10/08 04:42, cwsupport wrote:
The NTP server comes up down like a yoyo during system boot
How did you determine this?
I see lots of ntp started messages during startup.
--
ntp brought up before network is ready; fails not resolve any ip or host
Hi,
Im not sure that will help as the permissions of the installed sasldb
are root.root with no acl on it.
Perhaps the issue is two-fold, the cyrus-common-2.2 install (which I
think creates the user) should include the sasl group permission for the
cyrus user, and cyrus-sasl2 should correct the
Hi,
The cyrus user *is* in the sasl group. However the permissions on
/etc/sasldb2 are root.root.
I believe this should either be cryus.sasl or as a minimum root.sasl
TTFN
Barry
Scott Kitterman wrote:
Interesting. I checked a couple of my boxes and it was in the sasl
group.
--
This IS NOT fixed. Using 4.2.4p4+dfsg-3ubuntu2 on 8.04.1 I have 3
machines doing this and ALL failing.
The NTP server comes up down like a yoyo during system boot - which is
laughable.
The when ntpd is executed from init.d to bring the services up as expected it
fails becuase the socket isnt
Hi,
All fresh installs. ntp installed POST installation via apt-get.
Ubuntu Server 8.04.1 Kubuntu Desktop 8.04.1 KDE4 Remix.
Mixture of DHCP and static IP.
- As an example the desktop I am email from had 4 network interfaces. 2
static IP and 2 DHCP all specified under /etc/network/interfaces. 2
Public bug reported:
Binary package hint: sasl2-bin
Ubuntu: 8.04.1
Version: 2.1.22.dfsg1-18ubuntu2
The Cyrus IMAP server runs as the user cyrus. But the /etc/sasl2db does
not provide sufficient permissions for direct access by the IMAP server.
saslauthd has no problems as it runs as root.
Fix:
Public bug reported:
Binary package hint: nut
Ubuntu Server: 8.04.1
nut: 2.2.1-2.1ubuntu7.1
The 'nut' user is not given access to the serial ports. This is because
during install of the 'nut' package the user was not added to the
'dialout' group.
Fix:
usermod -g nut -G dialout nut
**
20 matches
Mail list logo
