Re: [Bug 456224] Re: Installing bind9 with forwarders causes loss of hostname resolution.
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 *not* delete any lines in /etc/resolv.conf. It doesn't even use the entries in /etc/resolv.conf to setup forwarders (ie the default bind9 configuration isn't a local cache). I never said the installer did this. I moved the lines from resolv.conf to the forwarders section. Before this is discounted though how come DIG still resolves (i.e. automatically uses 127.0.0.1) yet PING (and other programs) don't? DIG bypasses the libc stack (and thus resolv.conf - the same way has host does) while ping uses the libc stack (and thus uses the information from resolv.conf). Is the resolvconf package installed on the system? Yes. Is this expected behaviour from dig? If so then I suspect the libc stack has been fixed and no longer auto-resolves using 127.0.0.1 for DNS services. In which case this can be closed as works for me. -- Sincerely Yours Copyright Witness Net Support netsupp...@copyrightwitness.net www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- 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 list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 456224] Re: Installing bind9 with forwarders causes loss of hostname resolution.
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 resolves (i.e. automatically uses 127.0.0.1) yet PING (and other programs) don't? This is a CHANGE from operation under Hardy Heron - The reason for me raising the issue is to ascertain that this is now correct behaviour - given that ping and dig both work with an identical setup under hardy heron. Is it that the libc name resolution stack has changed? -- 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 list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 456224] [NEW] Installing bind9 with forwarders causes loss of hostname resolution.
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 has been configured to execute as a local-cache (i.e. no zones just
caching forwarded requests).
/etc/resolv.conf is EMPTY.
/etc/nsswitch.conf contains:
---
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
---
/etc/bind9/named.conf.options contains:
-
options {
directory /var/cache/bind;
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
212.139.132.43;
212.139.132.44;
};
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};
-
Taking the DNS servers into /etc/resolv.conf and uninstalling bind9 results in
hostname resolution being restored.
THIS WORKS UNDER Ubuntu Intrepid 8.04.
** Affects: bind9 (Ubuntu)
Importance: Undecided
Status: New
--
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 list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 456224] Re: Installing bind9 with forwarders causes loss of hostname resolution.
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 list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 applied in /etc/default to handle this? ** Attachment added: Patch /etc/init.d/ntp to ensure date is sycnd and hwclock is adjusted prior to executing ntp daemon. http://launchpadlibrarian.net/19293063/ntp.initd.patch -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 functionality. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 is set BUT the ntp daemon is NOT started. ** Attachment added: Patch to /etc/network/if-up.d/ntpdate. http://launchpadlibrarian.net/19293187/ntpdate.ifupd.patch -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 therefore addresses on a local DNS based server will resolve. Testing shows this works a treat and doesnt interfere with my laptop's wireless card connection either. The test about ntpd running is merely to determine whether or not to use the init.d script and restart. If its not running you wont get 'no association IDs' - you will get 'connection refused' when using ntpq. Hope this helps, Barry J Carerra wrote: RE: the previous three... h...I am sure I have seen cases where ntpd is running, but no associations are active; therefore, I am not sure that just testing if ntpd is running fully covers all possible cases.. -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 why it probably hasnt been picked up so far). The fix will be a god-send to anyone running a server that also hosts DNS (bind9 typically). The fix is therefore more important to corporates. Most end-users not running DNS servers probably wonder what all the current fuss is about. TTFN Barry J Carerra wrote: You say addresses on a local DNS server will resolve. What about the vast majority of people who do not have a local DNS server and rely on internet DNS? -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 S20hotkey-setup S20jboss S20nfs-common S20nfs-kernel-server S20nvidia-kernel S20powernowd S20rsync S20samba S20saslauthd S20ser2net S20winbind S20xl2tpd S23ntp As you can see S23ntp is up WAY after bind9. DNS clients resolving using gethostbyname() only need the network up - and on worst case (i.e. my machine with a caching DNS server) it needs to be up after S15bind9. It seems to me the problem is that NTP is run before the *network* cards are brought up properly (certainly before eth0). By the time it hits S23ntp the damage was already done a long time before. Resolution is based around /etc/nsswitch.conf, /etc/hosts and /etc/resolv.conf. As it happens I am running caching DNS servers (bind9) on all these machines as well - to fail to obtain the host that means NTP is being executed PRIOR to S15bind9. Now I have to say...the situation with the NTP daemon is a farce and there have been so many people 'tampering' with NTPD startup that quite frankly the use of /etc/rc2.d scripts is being completely undermined. What is needed is a proper solution here rather than yet more tampering. The NTP daemon is being started already from around 3 different places. It is the ordering and interaction of these which is causing the problems - coupled with the fact that the NTP daemon itself does not perform any kind of retry-recovery internally. Thomas wrote: I just finished a fresh U8.10-rc install. Plain vanilla, all I added was the NTP package. [EMAIL PROTECTED]:~$ ls -l /etc/rc5.d/S2[38]* lrwxrwxrwx 1 root root 13 Oct 26 14:18 /etc/rc5.d/S23ntp - ../init.d/ntp lrwxrwxrwx 1 root root 24 Oct 26 10:10 /etc/rc5.d/S28NetworkManager - ../init.d/NetworkManager NTP starts before Network Manager, meaning that NTP won't have DNS available at startup. It tends to work, but moving NTP's startup after Network Managers should make it more reliable. It will also allow NTPDATE to run (it's called from the ip-up scripts, but will fail as NTPD will already own the socket). [EMAIL PROTECTED]:~$ grep ntp-server /etc/dhcp3/dhclient.conf [EMAIL PROTECTED]:~$ NTP servers still aren't requested by default. If whoever set up your DHCP server knows enought to advertise NTP server(s) then chances are you should use them (or at the very least PREPEND them). -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 properlybut im a couple of months away of being able to fit that into my workload. The question I have yet to resolve is *what* is pulling NTPD up prior to S15bind9 being executed (and I reckon it happens more than once!). If NTP worked as I suggested in 288914 then all this messing about in dhcp scripts, ifup scripts etc would completely disappear and we can stick with just executing ntpd once from S23ntp quite happily - or even earlier if desired. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 288478] Re: Ownership of /etc/sasl2db precludes direct access by Cyrus IMAP
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 group access on the /etc/sasldb2 file to be root.sasl ? Is it expected that all access will go through saslauthd? I used to run this but changed to having the imap service access the sasldb directly which saves memory etc as there is no need for me to run the saslauthd service at all. Or does this come under one of those cross-package configuration issues that are basically resolved by hand? Cheers, Barry Scott Kitterman wrote: Adding cyrus to the sasl group should also solve it. I don't think this is an actual bug in cyrus-sasl2. -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- Ownership of /etc/sasl2db precludes direct access by Cyrus IMAP https://bugs.launchpad.net/bugs/288478 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cyrus-sasl2 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 288478] Re: Ownership of /etc/sasl2db precludes direct access by Cyrus IMAP
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. -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- Ownership of /etc/sasl2db is root:root instead of root:sasl https://bugs.launchpad.net/bugs/288478 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cyrus-sasl2 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 available. ntpq -p after login states 'no association IDs'. ifdown --all ifup --all fixes - as does /etc/init.d/ntp restart ** Changed in: ntp (Ubuntu Hardy) Status: Fix Released = New -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 114505] Re: ntp brought up before network is ready; fails not resolve any ip or host names; ntp does not recover
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 static both cabled, gateway specified on one of them. 2 marked as DHCP not connected. Only eth0 and eth1 marked as auto. This typical of 5 server installs and 3 desktop installs which are all have this issue. The machine it *does* work is a laptop with eth0 (DHCP not connected) and ath0 (WPA wireless managed by knetworkmanager). This seems to always come up OK. But that is probably because the wireless network comes up under ifup post-login and the ifup scripts are probably doing their job. I cannot remember if it works properly under a cabled eth0 with DHCP as I always use the wireless on the laptop. Hope this helps, Barry Onno Benschop wrote: The machines that you are having issues with, were they fresh hardy installs, upgrades, or a mixture? How are their network interfaces managed? Are they running Ubuntu, or Ubuntu-server? In re-reading this bug-report, I can see there are many issues that appear to affect this bug and the NTP server restarting several times during boot appears to be related to the several ways in which it's started. While not ideal by any stretch of the imagination, the aim was to get to a point after boot at which time ntpdate had succesfully run and NTP - if installed - was running. From your report, this does not appear to be the case. ** Changed in: ntp (Ubuntu Hardy) Status: New = Incomplete -- Sincerely Yours Copyright Witness Net Support [EMAIL PROTECTED] www.copyrightwitness.com Registration centre for copyright works. This e-mail and any attachments are confidential and intended for the addressee only. The information in this mail does not amount to legal advice or opinion. Any views or legal references are those of the author and are based on personal opinion or understanding only. -- 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 assignee. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 288478] [NEW] Ownership of /etc/sasl2db precludes direct access by Cyrus IMAP
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: chown cyrus.sasl /etc/sasl2db ** Affects: cyrus-sasl2 (Ubuntu) Importance: Undecided Status: New -- Ownership of /etc/sasl2db precludes direct access by Cyrus IMAP https://bugs.launchpad.net/bugs/288478 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cyrus-sasl2 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 287781] [NEW] Nut UPS user does not have access to the serial ports.
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 ** Affects: nut (Ubuntu) Importance: Undecided Status: New -- Nut UPS user does not have access to the serial ports. https://bugs.launchpad.net/bugs/287781 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nut in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
