[Bug 1094830] [NEW] brcompat failed to be loaded
Public bug reported: 1 fresh 12.04.1 installation 2 install openvswitch-datapath-dkms and build-essential 3 try to load the module by using modrpobe, got the error FATAL: Error inserting brcompat_mod (/lib/modules/3.2.0-29-generic/updates/dkms/brcompat_mod.ko): Invalid module format ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: openvswitch-datapath-dkms 1.4.0-1ubuntu1.3 ProcVersionSignature: Ubuntu 3.2.0-29.46-generic 3.2.24 Uname: Linux 3.2.0-29-generic x86_64 ApportVersion: 2.0.1-0ubuntu12 Architecture: amd64 Date: Mon Dec 31 16:05:07 2012 InstallationMedia: Ubuntu-Server 12.04.1 LTS Precise Pangolin - Release amd64 (20120817.3) PackageArchitecture: all SourcePackage: openvswitch UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: openvswitch (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug precise -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openvswitch in Ubuntu. https://bugs.launchpad.net/bugs/1094830 Title: brcompat failed to be loaded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1094830/+subscriptions -- 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 1016744] Re: OpenVPN example easy-rsa 2.0 issues
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: openvpn (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1016744 Title: OpenVPN example easy-rsa 2.0 issues To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1016744/+subscriptions -- 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 1033727] Re: USB passthrough doesn't work anymore with qemu-kvm 1.1.1
same here with AVM ISDN-Controller FRITZ!Card v2.1 on openSUSE 12.2. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1033727 Title: USB passthrough doesn't work anymore with qemu-kvm 1.1.1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1033727/+subscriptions -- 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 1094921] [NEW] keystone postinst fails with KeyError: VerNum(4)
Public bug reported: When upgrading from 2012.1+stable~20120824-a16a0ab9-0ubuntu2.2 to 2012.1+stable~20120824-a16a0ab9-0ubuntu2.3 (lovely version numbers, by the way), I'm getting the following spew from the postinst: | Setting up keystone (2012.1+stable~20120824-a16a0ab9-0ubuntu2.3) ... | Traceback (most recent call last): | File /usr/bin/keystone-manage, line 28, in module | cli.main(argv=sys.argv, config_files=config_files) | File /usr/lib/python2.7/dist-packages/keystone/cli.py, line 148, in main | return run(cmd, (args[:1] + args[2:])) | File /usr/lib/python2.7/dist-packages/keystone/cli.py, line 134, in run | return CMDS[cmd](argv=args).run() | File /usr/lib/python2.7/dist-packages/keystone/cli.py, line 36, in run | return self.main() | File /usr/lib/python2.7/dist-packages/keystone/cli.py, line 57, in main | driver.db_sync() | File /usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py, line 135, in db_sync | migration.db_sync() | File /usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py, line 54, in db_sync | CONF.sql.connection, repo_path, version) | File /usr/lib/python2.7/dist-packages/migrate/versioning/api.py, line 186, in upgrade | return _migrate(url, repository, version, upgrade=True, err=err, **opts) | File string, line 2, in _migrate | File /usr/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py, line 159, in with_engine | return f(*a, **kw) | File /usr/lib/python2.7/dist-packages/migrate/versioning/api.py, line 345, in _migrate | changeset = schema.changeset(version) | File /usr/lib/python2.7/dist-packages/migrate/versioning/schema.py, line 80, in changeset | changeset = self.repository.changeset(database, start_ver, version) | File /usr/lib/python2.7/dist-packages/migrate/versioning/repository.py, line 225, in changeset | changes = [self.version(v).script(database, op) for v in versions] | File /usr/lib/python2.7/dist-packages/migrate/versioning/repository.py, line 189, in version | return self.versions.version(*p, **k) | File /usr/lib/python2.7/dist-packages/migrate/versioning/version.py, line 140, in version | return self.versions[VerNum(vernum)] | KeyError: VerNum(4) | dpkg: error processing keystone (--configure): | subprocess installed post-installation script returned error exit status 1 This is on Ubuntu 12.04 with precise-proposed enabled. ** Affects: keystone (Ubuntu) Importance: Undecided Status: New ** Tags: canonistack ** Tags added: canonistack -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to keystone in Ubuntu. https://bugs.launchpad.net/bugs/1094921 Title: keystone postinst fails with KeyError: VerNum(4) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1094921/+subscriptions -- 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 1091602] Re: Please add resolvconf hook script to generate dynamic forwarders list
** No longer affects: bind ** Also affects: bind9 (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483098 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bind9 in Ubuntu. https://bugs.launchpad.net/bugs/1091602 Title: Please add resolvconf hook script to generate dynamic forwarders list To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1091602/+subscriptions -- 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 933723] Re: bind9 registering itself with resolvconf but not set up to forward queries
Link to similar upstream bug report with title Please default to RESOLVCONF=no (Upstream bug report #483098 is now being tracked in Launchpad by wishlist bug #1091602 with title Please add resolvconf hook script to generate dynamic forwarders list.) ** Bug watch added: Debian Bug tracker #538674 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538674 ** Changed in: bind9 (Debian) Status: New = Unknown ** Changed in: bind9 (Debian) Remote watch: Debian Bug tracker #483098 = Debian Bug tracker #538674 ** Summary changed: - bind9 registering itself with resolvconf but not set up to forward queries + bind9 registers itself with resolvconf even though it's unable to provide name service -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bind9 in Ubuntu. https://bugs.launchpad.net/bugs/933723 Title: bind9 registers itself with resolvconf even though it's unable to provide name service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/933723/+subscriptions -- 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 933723] Re: bind9 registers itself with resolvconf even though it's unable to provide name service
** Changed in: bind9 (Debian) Status: Unknown = New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bind9 in Ubuntu. https://bugs.launchpad.net/bugs/933723 Title: bind9 registers itself with resolvconf even though it's unable to provide name service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/933723/+subscriptions -- 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 1094944] [NEW] squid3 remove doesn't delete logrotate conf file
You have been subscribed to a public bug: It appears that removing squid3 does not delete the file /etc/logrotate.d/squid3. I installed squid3, and then did # apt-get remove squid3 # apt-get autoremove The next night, I received a cron error email containing: /etc/cron.daily/logrotate: logrotate_script: 2: logrotate_script: /usr/sbin/squid3: not found error: error running shared postrotate script for '/var/log/squid3/*.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 I checked /etc/logrotate.d and discovered a file named squid3. After deleting it, I ran # /etc/cron.daily/logrotate and did not get any errors. ** Affects: squid3 (Ubuntu) Importance: Undecided Status: New -- squid3 remove doesn't delete logrotate conf file https://bugs.launchpad.net/bugs/1094944 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 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 1094944] [NEW] squid3 remove doesn't delete logrotate conf file
Public bug reported: It appears that removing squid3 does not delete the file /etc/logrotate.d/squid3. I installed squid3, and then did # apt-get remove squid3 # apt-get autoremove The next night, I received a cron error email containing: /etc/cron.daily/logrotate: logrotate_script: 2: logrotate_script: /usr/sbin/squid3: not found error: error running shared postrotate script for '/var/log/squid3/*.log ' run-parts: /etc/cron.daily/logrotate exited with return code 1 I checked /etc/logrotate.d and discovered a file named squid3. After deleting it, I ran # /etc/cron.daily/logrotate and did not get any errors. ** Affects: squid3 (Ubuntu) Importance: Undecided Status: New ** Project changed: launchpad = squid3 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/1094944 Title: squid3 remove doesn't delete logrotate conf file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1094944/+subscriptions -- 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 1091430] Re: 9p fails with readonly+non-root due to O_NOATIME
The description was updated; are the described procedure and expected/actual results appropriate? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/1091430 Title: 9p fails with readonly+non-root due to O_NOATIME To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1091430/+subscriptions -- 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 1091602] Re: Please add resolvconf hook script to generate dynamic forwarders list
** Description changed:
- This is a wish. It is requested that the bind9 package include a
- resolvconf hook script /etc/resolvconf/update.d/bind9 which writes a
- forwarders{} statement to /var/run/named/forwarders based on the
- nameserver information in resolvconf's database. Then in order to use
- named in whole or in part as a forwarding nameserver the administrator
- can simply modify named.conf so that the latter includes
- /var/run/named/forwarders at the right place in the file. If this
- inclusion could be controlled by a setting in, e.g., /etc/default/bind9,
- then that would be even nicer.
+ It is requested that the bind9 package be enhanced such that named uses
+ forwarder addresses obtained from resolvconf's database.
- The file /etc/resolvconf/update.d/bind included in resolvconf versions
- 1.52 and earlier illustrates how such a hook script should be written.
- The latter file was written for BIND 8 and worked well; but due to
- limitations in BIND 8 it had to generate a whole options statement
- instead of just the forwarders part, which was less nice.
+ Such a feature would normally be implemented by means of a resolvconf
+ update hook script, in this case /etc/resolvconf/update.d/bind9. (It
+ must *not* be called /etc/resolvconf/update.d/bind since that was the
+ name of a script written for BIND 8 and included in earlier versions of
+ resolvconf.) Resolvconf update hook scripts get run every time the
+ database changes.
- I am prepared to write the needed script for BIND 9 and attach it here.
+ There are various ways to implement this proposal.
+
+ 1. Write out a forwarders{} statement
+
+ The script writes out a forwarders{} statement in the format of
+ named.conf(5) to /var/run/named/named.conf.forwarders and then does
+ /etc/init.d/bind9 reload to cause named to re-read its configuration
+ files.
+
+ To activate this, the admin has to edit /etc/bind/named.conf.options
+ such that it includes /var/run/named/named.conf.forwarders at the right
+ place.
+
+ The script /etc/resolvconf/update.d/bind that was included in resolvconf
+ versions 1.52 and earlier illustrates how such a hook script should be
+ written. The latter script was written for BIND 8 and worked well, but
+ due to limitations in BIND 8 it had to generate a whole options{}
+ statement instead of just the forwarders{} part.
+
+ 2. Write a list of forwarder addresses and enhance named to read this
+
+ The script writes out a simple list of IP addresses to
+ /var/run/named/forwarders and then triggers named to re-read its
+ forwarders list from this file. When run with a new option,
+ --forwarders-list=/var/run/named/forwarders, named uses the list in
+ /var/run/named/forwarders as its list of forwarder addresses instead of
+ whatever list was specified in the configuration file.
+
+ This approach requires that the option in question be added to named but
+ it has a number of advantages over the first approach. (1) It allows the
+ script to be much simpler. (2) It avoids run-time generation of
+ configuration files. (3) It avoids triggering the re-reading of
+ configuration files. (4) It allows the use of the resolvconf-based
+ forwarders list to be enabled and disabled via a variable in
+ /etc/default/bind9. (5) Some machines are still using an old script
+ written for bind8 which works as in #1 except that it writes out a whole
+ options{} statement instead of just a forwarders{} statement; the
+ present approach upgrades such machines cleanly.
--- BACKGROUND INFORMATION ---
As of Ubuntu 12.04, nameserver information is handled by resolvconf in
both the Server and Desktop editions of Ubuntu. Resolvconf maintains a
database of nameserver information, filed by interface name and
configuration agent. This is the information that is needed if named is
to be used in whole or in part as a forwarding nameserver.
BIND 9.7.x manual section 1.4.5.1: __Forwarding__. Even a caching name
server does not necessarily perform the complete recursive lookup
itself. Instead, it can forward some or all of the queries that it
cannot satisfy from its cache to another caching name server, commonly
referred to as a forwarder. There may be one or more forwarders, and
they are queried in turn until the list is exhausted or an answer is
found. Forwarders are typically used when you do not wish all the
servers at a given site to interact directly with the rest of the
Internet servers. A typical scenario would involve a number of internal
DNS servers and an Internet firewall. Servers unable to pass packets
through the firewall would forward to the server that can do it, and
that server would query the Internet DNS servers on the internal
server’s behalf.
-
- Currently it's possible to configure named to use a static list of
- forwarders, but to make use of a dynamic list a resolvconf hook script
- is needed.
--
You received this bug notification because you are a member of Ubuntu
[Bug 1091602] Re: Please add resolvconf hook script to generate dynamic forwarders list
** Description changed:
It is requested that the bind9 package be enhanced such that named uses
forwarder addresses obtained from resolvconf's database.
Such a feature would normally be implemented by means of a resolvconf
update hook script, in this case /etc/resolvconf/update.d/bind9. (It
must *not* be called /etc/resolvconf/update.d/bind since that was the
name of a script written for BIND 8 and included in earlier versions of
resolvconf.) Resolvconf update hook scripts get run every time the
database changes.
There are various ways to implement this proposal.
1. Write out a forwarders{} statement
The script writes out a forwarders{} statement in the format of
named.conf(5) to /var/run/named/named.conf.forwarders and then does
/etc/init.d/bind9 reload to cause named to re-read its configuration
files.
To activate this, the admin has to edit /etc/bind/named.conf.options
such that it includes /var/run/named/named.conf.forwarders at the right
place.
The script /etc/resolvconf/update.d/bind that was included in resolvconf
versions 1.52 and earlier illustrates how such a hook script should be
written. The latter script was written for BIND 8 and worked well, but
due to limitations in BIND 8 it had to generate a whole options{}
statement instead of just the forwarders{} part.
2. Write a list of forwarder addresses and enhance named to read this
The script writes out a simple list of IP addresses to
- /var/run/named/forwarders and then triggers named to re-read its
- forwarders list from this file. When run with a new option,
- --forwarders-list=/var/run/named/forwarders, named uses the list in
- /var/run/named/forwarders as its list of forwarder addresses instead of
- whatever list was specified in the configuration file.
+ /var/run/named/forwarders and then does /etc/init.d/bind9 reload to
+ cause named to re-read its configuration files. When run with a new
+ command-line option, --forwarders-list=/var/run/named/forwarders,
+ named uses the list in /var/run/named/forwarders as its list of
+ forwarder addresses instead of whatever was specified in options{}.
- This approach requires that the option in question be added to named but
- it has a number of advantages over the first approach. (1) It allows the
- script to be much simpler. (2) It avoids run-time generation of
- configuration files. (3) It avoids triggering the re-reading of
- configuration files. (4) It allows the use of the resolvconf-based
- forwarders list to be enabled and disabled via a variable in
- /etc/default/bind9. (5) Some machines are still using an old script
- written for bind8 which works as in #1 except that it writes out a whole
- options{} statement instead of just a forwarders{} statement; the
- present approach upgrades such machines cleanly.
+ This approach requires that the command-line option in question be added
+ to named but it has a number of advantages over the first approach. (1)
+ It allows the script to be much simpler. (2) It allows the use of the
+ resolvconf-based forwarders list to be enabled and disabled via a
+ variable in, e.g., /etc/default/bind9. (3) Some machines are still using
+ an old script written for bind8 which works as in #1 except that it
+ writes out a whole options{} statement instead of just a forwarders{}
+ statement; the present approach upgrades such machines cleanly.
+
+ 3. Enhance rndc to send, and named to receive, forwarder addresses
+
+ This has the advantages of approach #2 and also eliminates the need to
+ write out a file. The disadvantage is that it would be a significant
+ amount of extra work to extend the syntax of rndc.
--- BACKGROUND INFORMATION ---
As of Ubuntu 12.04, nameserver information is handled by resolvconf in
both the Server and Desktop editions of Ubuntu. Resolvconf maintains a
database of nameserver information, filed by interface name and
configuration agent. This is the information that is needed if named is
to be used in whole or in part as a forwarding nameserver.
BIND 9.7.x manual section 1.4.5.1: __Forwarding__. Even a caching name
server does not necessarily perform the complete recursive lookup
itself. Instead, it can forward some or all of the queries that it
cannot satisfy from its cache to another caching name server, commonly
referred to as a forwarder. There may be one or more forwarders, and
they are queried in turn until the list is exhausted or an answer is
found. Forwarders are typically used when you do not wish all the
servers at a given site to interact directly with the rest of the
Internet servers. A typical scenario would involve a number of internal
DNS servers and an Internet firewall. Servers unable to pass packets
through the firewall would forward to the server that can do it, and
that server would query the Internet DNS servers on the internal
server’s behalf.
** Summary changed:
- Please add resolvconf hook
[Bug 1055567] Re: open-vm-dkms 2011.12.20-562307-0ubuntu1: open-vm-tools kernel module failed to build [erreur: ‘INVALID’ undeclared]
[Expired for open-vm-tools (Ubuntu) because there has been no activity for 60 days.] ** Changed in: open-vm-tools (Ubuntu) Status: Incomplete = Expired -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to open-vm-tools in Ubuntu. https://bugs.launchpad.net/bugs/1055567 Title: open-vm-dkms 2011.12.20-562307-0ubuntu1: open-vm-tools kernel module failed to build [erreur: ‘INVALID’ undeclared] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1055567/+subscriptions -- 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 1094984] [NEW] /etc/aliases does not work (dpkg-reconfigure error)
Public bug reported: ## Bug Summary: Mail send from the localhost to root will not follow /etc/aliases in smarthost config due to dpkg-reconfigure exim4-config error. (solution provided in the end) ## Setting: exim4 (4.76-3ubuntu3.1) configured as smarthost without local mail delivery. // installed packages root@hostX (0)# dpkg-query -l 'exim4*' /etc Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii exim4 4.76-3ubuntu3.1 metapackage to ease Exim MTA (v4) installation ii exim4-base4.76-3ubuntu3.1 support files for all Exim MTA (v4) packages ii exim4-config 4.76-3ubuntu3.1 configuration for the Exim MTA (v4) un exim4-config-2none(no description available) un exim4-daemon-custom none(no description available) un exim4-daemon-heavynone(no description available) ii exim4-daemon-light4.76-3ubuntu3.1 lightweight Exim MTA (v4) daemon un exim4-doc-htmlnone(no description available) un exim4-doc-infonone(no description available) un exim4-localscanapi-1. none(no description available) un exim4-localscanapi-1. none(no description available) // dpkg-reconfigure exim4-config (relevant ones) mail server configuration type: mail sent by smarthost; no local mail mail name: hostX.domainY ## same as ´hostname -A´ ... Other destinations for which mail is accepted: hostX.domainZ;hostX.domainA // nano /etc/aliases mailer-daemon: postmaster postmaster: root nobody: root root: m...@example.org / /etc/exim4/passwd.client The user account used for mail transport is different from m...@example.org (someth...@gmail.com in my case) ## Bug: mail send from the host to root will never go to m...@example.org regardless of /etc/aliases config ## Root cause: dpkg-reconfigure exim4-config does not add mailname (hostX.domainY) into MAIN_LOCAL_DOMAINS. This causes exim4 to skip /etc/aliases since root is automatically expanded to root@hostX.domainY which is not identified as local address due to hostX.domainY missing from MAIN_LOCAL_DOMAINS // less /var/lib/exim4/config.autogenerated (search MAIN_LOCAL_DOMAINS) .ifndef MAIN_LOCAL_DOMAINS MAIN_LOCAL_DOMAINS=@:localhost:hostX.domainZ:hostX.domainA (mail name hostX.domainY is missing!) .endif FYI: @ denotes hostname without domain part ## Solution 1) Automatically add mail name (hostX.domainY in this example) into MAIN_LOCAL_DOMAINS in dpkg-reconfigure 2) Change the text in dpkg-reconfigure to explain that for some reason (???) user needs to re-type mail name (hostname -A) into the field. The current text misleadingly mentions only _other_ destinations. PS. It seems the issue has been here long: http://lists.alioth.debian.org/pipermail/pkg-exim4-users/2009-June/001636.html ** Affects: exim4 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to exim4 in Ubuntu. https://bugs.launchpad.net/bugs/1094984 Title: /etc/aliases does not work (dpkg-reconfigure error) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1094984/+subscriptions -- 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 1094984] Re: /etc/aliases does not work (dpkg-reconfigure error)
** Description changed: - (solution in the end) + ## Bug Summary: + Mail send from the localhost to root will not follow /etc/aliases in smarthost config due to dpkg-reconfigure exim4-config error. - ## Setting: exim4 (4.76-3ubuntu3.1) configured as smarthost without local mail delivery. + (solution provided in the end) + + ## Setting: exim4 (4.76-3ubuntu3.1) configured as smarthost without local mail delivery. // installed packages root@hostX (0)# dpkg-query -l 'exim4*' /etc Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii exim4 4.76-3ubuntu3.1 metapackage to ease Exim MTA (v4) installation ii exim4-base4.76-3ubuntu3.1 support files for all Exim MTA (v4) packages ii exim4-config 4.76-3ubuntu3.1 configuration for the Exim MTA (v4) un exim4-config-2none(no description available) un exim4-daemon-custom none(no description available) un exim4-daemon-heavynone(no description available) ii exim4-daemon-light4.76-3ubuntu3.1 lightweight Exim MTA (v4) daemon un exim4-doc-htmlnone(no description available) un exim4-doc-infonone(no description available) un exim4-localscanapi-1. none(no description available) un exim4-localscanapi-1. none(no description available) // dpkg-reconfigure exim4-config (relevant ones) mail server configuration type: mail sent by smarthost; no local mail mail name: hostX.domainY ## same as ´hostname -A´ ... Other destinations for which mail is accepted: hostX.domainZ;hostX.domainA // nano /etc/aliases mailer-daemon: postmaster postmaster: root nobody: root root: m...@example.org - / /etc/exim4/passwd.client + / /etc/exim4/passwd.client The user account used for mail transport is different from m...@example.org (someth...@gmail.com in my case) - ## Bug: + ## Bug: mail send from the host to root will never go to m...@example.org regardless of /etc/aliases config ## Root cause: dpkg-reconfigure exim4-config does not add mailname (hostX.domainY) into MAIN_LOCAL_DOMAINS. This causes exim4 to skip /etc/aliases since root is automatically expanded to root@hostX.domainY which is not identified as local address due to hostX.domainY missing from MAIN_LOCAL_DOMAINS - // less /var/lib/exim4/config.autogenerated + // less /var/lib/exim4/config.autogenerated (search MAIN_LOCAL_DOMAINS) .ifndef MAIN_LOCAL_DOMAINS MAIN_LOCAL_DOMAINS=@:localhost:hostX.domainZ:hostX.domainA (mail name hostX.domainY is missing!) .endif FYI: @ denotes hostname without domain part ## Solution 1) Automatically add mail name (hostX.domainY in this example) into MAIN_LOCAL_DOMAINS in dpkg-reconfigure 2) Change the text in dpkg-reconfigure to explain that for some reason (???) user needs to re-type mail name (hostname -A) into the field. The current text misleadingly mentions only _other_ destinations. PS. It seems the issue has been here long: http://lists.alioth.debian.org/pipermail/pkg-exim4-users/2009-June/001636.html -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to exim4 in Ubuntu. https://bugs.launchpad.net/bugs/1094984 Title: /etc/aliases does not work (dpkg-reconfigure error) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1094984/+subscriptions -- 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
