[Bug 1683229] Re: package mariadb-server-10.1 failed to install since mysql-server-5.7 isn't purged
Note that purging MySQL 5.7 server prior Installing MariaDB 10.1 won't work neither due to apparmor profile. At least, MariaDB server won't start. See https://bugs.launchpad.net/ubuntu/+source/mariadb-10.1/+bug/1806263 Env: Ubuntu Bionic Beaver ;) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1683229 Title: package mariadb-server-10.1 failed to install since mysql-server-5.7 isn't purged To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.1/+bug/1683229/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1806263] [NEW] MariaDB 10.1 server won't start when MySQL 5.7 server has been previously installed
Public bug reported: If you purge MySQL 5.7 server, then install MariaDB 10.1, that last won't start due to wrong AppArmor profile. CURRENT RESULT ON mariadb-server-10.1 package installation ... Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details. ... # LANG=C systemctl status mariadb * mariadb.service - MariaDB 10.1.34 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Sun 2018-12-02 17:26:09 UTC; 59s ago Docs: man:mysqld(8) https://mariadb.com/kb/en/library/systemd/ Main PID: 23245 (code=exited, status=0/SUCCESS) Dec 02 17:24:37 bionic systemd[1]: Starting MariaDB 10.1.34 database server... Dec 02 17:24:37 bionic mysqld[23245]: 2018-12-02 17:24:37 139820621216896 [Note] /usr/sbin/mysqld (mysqld 10.1.34-MariaDB-0ubuntu0.18.04.1) starting as process 23245 ... Dec 02 17:26:07 bionic systemd[1]: mariadb.service: Start operation timed out. Terminating. Dec 02 17:26:09 bionic systemd[1]: mariadb.service: Failed with result 'timeout'. Dec 02 17:26:09 bionic systemd[1]: Failed to start MariaDB 10.1.34 database server. EXPECTED RESULT MariaDB 10.1 server starting as expected. HOWTO REPRODUCE apt-get install mysql-server-5.7 mysql-client-5.7 apt-get purge mysql-server-5.7 mysql-client-5.7 apt-get install mariadb-server-10.1 mariadb-client-10.1 DISCUSSION The mysql-server-5.7 package install an /etc/apparmor.d/usr.sbin.mysqld APPARMOR(7) profile: # dpkg -S /etc/apparmor.d/usr.sbin.mysqld mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld When purging the mysql-server-5.7 server package get purged, the /etc/apparmor.d/usr.sbin.mysqld profile is also removed but, it is still loaded: # aa-status | grep 'mysqld' /usr/sbin/mysqld This lead to MariaDB 1.0 server not being able to start due to MySQL 5.7 APPARMOR(7) profile that is still loaded. Furthermore, the mariadb-server-10.1 also comes with an APPARMOR(7) profile which as per it header comments is "intensionally empty to disable apparmor by default for newer versions of MariaDB". This is a big mistake as such a profile is simply wrong in regard of APPARMOR_PARSER(8) and as such, won't be unloaded: # apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld # aa-status | grep 'mysqld' /usr/sbin/mysqld while: # echo "/usr/sbin/mysqld { }" > /etc/apparmor.d/usr.sbin.mysqld # apparmor_parser -v -R /etc/apparmor.d/usr.sbin.mysqld Removal succeeded for "/usr/sbin/mysqld". # aa-status | grep 'mysqld' FIX PROPOSAL 1. When mysql-server-5.7 package is being removed/purged, the APPARMOR(7) profile should be unloaded and removed ranther than be simply removed. 2. The profile provided by the mariadb-server-10.1 package should have correct syntax in regard of APPARMOR_PARSER(8) 3. The mariadb-server-10.1 package postinst/postrm maintainer scripts should handle apparmor profile (load/unload) Env Ubuntu Bionic Beaver (18.04) ** Affects: mariadb-10.1 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1806263 Title: MariaDB 10.1 server won't start when MySQL 5.7 server has been previously installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.1/+bug/1806263/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1702677] Re: Add an option to override version prefix (~ubuntu)
We need that too ;) That's really a valuable addition. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702677 Title: Add an option to override version prefix (~ubuntu) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1702677/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1633754] Re: dirmngr is used as daemon
@Julian So, if I understand well, you want remove the APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE environment variable but keep the warning when APT-KEY detect that its output is captured? That would be tedious for us.. We do not want such a warn in our case. We capture STDOUT for the purpose of debugging (STDOUT goes to a log file and is print to screen, depending on context). Sometime, you should let developers take decisions. If they are not able to stick to the man page recommendations, that not your problem, isn't it? Or do you consider that all developers are idiot? BTW: It seem that simply putting keys into the trusted directory is not sufficient. APT still warn about missing PUBKEY... See also https://askubuntu.com/questions/31286/additional-keyrings-for-apt-in- trusted-gpg-d -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1633754 Title: dirmngr is used as daemon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1633754/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1633754] Re: dirmngr is used as daemon
@Julian Thank for your advise. So basically, putting keys into the trusted.gpg.d directory should be sufficient to make APT happy? I never tried that way, even worse (shame on me), I was not aware of that possibility... Regarding the environment variable, I really don't understand why we are warned. Capturing APT stdout doesn't necessarily mean parsing process... Even through, developers which invoke APT in automation script should known what they are doing. At least, a simple warn in the documentation should be sufficient... So yes, I'm with out on that point, that warn, should be dropped. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1633754 Title: dirmngr is used as daemon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1633754/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1633754] Re: dirmngr is used as daemon
We get identical problem in our software installer. It seem that dirmngr processes never goes away. We workaround the issue by terminating the process manually: {code} =item addRepositories( @repositories ) See iMSCP::DistPackageManager::Interface::addRepositories() Param list @repositories List of repositories, each represented as a hash with the following key/value pairs: repository : APT repository in format 'uri suite [component1] [component2] [...]' repository_key_srv : APT repository key server such as keyserver.ubuntu.com (not needed if repository_key_uri is provided) repository_key_id : APT repository key identifier such as 5072E1F5 (not needed if repository_key_uri is provided) repository_key_uri : APT repository key URI such as https://packages.sury.org/php/apt.gpg (not needed if repository_key_id is provided) =cut sub addRepositories { my ( $self, @repositories ) = @_; $self->{'eventManager'}->trigger( 'beforeAddDistributionRepositories', \@repositories ) == 0 or die( getMessageByType( 'error', { amount => 1, remove => TRUE } ) || 'Unknown error' ); # Make sure that repositories are not added twice $self->removeRepositories( @repositories ); my $file = iMSCP::File->new( filename => $APT_SOURCES_LIST_FILE_PATH ); my $fileContent = $file->getAsRef(); # Add APT repositories for my $repository ( @repositories ) { ${ $fileContent } .= <<"EOF"; deb $repository->{'repository'} deb-src $repository->{'repository'} EOF # Hide "apt-key output should not be parsed (stdout is not a terminal)" warning that # is raised in newest apt-key versions. Our usage of apt-key is not dangerous (not parsing) local $ENV{'APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE'} = TRUE; if ( $repository->{'repository_key_srv'} && $repository->{'repository_key_id'} ) { # Add the repository key from the given key server my $rs = execute( [ 'apt-key', 'adv', '--recv-keys', '--keyserver', $repository->{'repository_key_srv'}, $repository->{'repository_key_id'} ], \my $stdout, \my $stderr ); debug( $stdout ) if length $stdout; $rs == 0 or die( $stderr || 'Unknown error' ); # Workaround https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1633754 execute( [ 'pkill', '-TERM', 'dirmngr' ], \$stdout, \$stderr ); } elsif ( $repository->{'repository_key_uri'} ) { # Add the repository key by fetching it first from the given URI my $keyFile = File::Temp->new(); $keyFile->close(); my $rs = execute( [ 'wget', '--prefer-family=IPv4', '--timeout=30', '-O', $keyFile, $repository->{'repository_key_uri'} ], \my $stdout, \my $stderr ); debug( $stdout ) if length $stdout; $rs == 0 or die( $stderr || 'Unknown error' ); $rs = execute( [ 'apt-key', 'add', $keyFile ], \$stdout, \$stderr ); debug( $stdout ) if length $stdout; $rs == 0 or die( $stderr || 'Unknown error' ); } } $file->save(); $self->{'eventManager'}->trigger( 'afterAddDistributionRepositories', \@repositories ) == 0 or die( getMessageByType( 'error', { amount => 1, remove => TRUE } ) || 'Unknown error' ); } {code} -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1633754 Title: dirmngr is used as daemon To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1633754/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
Le 27/10/2017 à 16:57, Mark Sapiro a écrit : > The fix is http://bazaar.launchpad.net/~mailman- > coders/mailman/2.1/revision/1714 > > I don't think it's a priority. I never saw an issue due to this before > this report. Also, in the case of Debian/Ubuntu, if the site takes the > postfix_to_mailman.py option (something which I don't recommend - see > https://wiki.list.org/x/15564817 - but which the Debian/Ubuntu package > seems to encourage), this is not relevant at all. > We don't make use of that postfix_to_mailman.py script which is really bad ;) BTW: We are using mailman on shared hosting where there are huge of lists. This bug is important to my eyes. -- Laurent Declercq iHMS/i-MSCP CEO & Lead Developer This message and any attachment are intended solely for the addressees and are confidential. iHMS/i-MSCP, including any part representing these entities may not be held responsible for their contents whose accuracy and completeness cannot be guaranteed over the Internet. Unauthorized use, disclosure, distribution, copying, or any part thereof is strictly prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1696066 Title: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
@msapiro I can confirm that the fixes solve the problems. Thank you for your involvement here. That is much appreciated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1696066 Title: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
** Description changed: Dear project leader At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch. Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map. In order, the following conditions have to be met: - Postfix need read access to the aliases.db file - Mailman like to be owner of those files and the Mailman group needs write access to them I. Postfix needs a read access to the aliases.db file We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664 II. Mailman group needs a write access to those files at any time The following behavior has been observed: When creating a new list on command line, using bin/newlist script as follow: # newlist -u virtualhost foobar the files will be created as follow: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db The same thing has been observed when recreating the file from scratch using bin/genaliases: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db Note that in both cases, files were not present. Thus, they were created from scratch. - As you can see here, the Mailman data/aliases table is created with the + As you can see here, the Mailman data/aliases file is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file. The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions). That is really a problem. Of course, one can just pre-create the files as follow: # cd /var/lib/mailman # sg list -c "touch data/aliases && postalias data/aliases" # chmod 0660 data/aliases* but that seem tedious. What if at some point (for any reason), the files get recreated from scratch? So, from my point of view, the MTA/Postfix.py module should always set correct permissions on *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg: IF NOT EXISTS aliases: Touch data/aliases data/aliases.db with correct permissions (066x) Add alias entries into aliases as usually Run POSTALIAS(1) command as usually Then, we are fine. Thank you. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1696066 Title: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696066/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
** Description changed: Dear project leader At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch. Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map. In order, the following conditions have to be met: - Postfix need read access to the aliases.db file - Mailman like to be owner of those files and the Mailman group needs write access to them I. Postfix needs a read access to the aliases.db file We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664 II. Mailman group needs a write access to those files at any time The following behavior has been observed: When creating a new list on command line, using bin/newlist script as follow: # newlist -u virtualhost foobar the files will be created as follow: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db The same thing has been observed when recreating the file from scratch using bin/genaliases: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db Note that in both cases, files were not present. Thus, they were created from scratch. As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file. The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions). That is really a problem. Of course, one can just pre-create the files as follow: # cd /var/lib/mailman # sg list -c "touch data/aliases && postalias data/aliases" # chmod 0660 data/aliases* but that seem tedious. What if at some point (for any reason), the files get recreated from scratch? So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least - when the files are created from scratch. + when the files are created from scratch. Eg: + + IF NOT EXISTS aliases: +Touch data/aliases data/aliases.db with correct permissions (066x) +Add alias entries into aliases as usually +Run POSTALIAS(1) command as usually + + Then, we are fine. Thank you. ** Description changed: Dear project leader At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch. Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map. In order, the following conditions have to be met: - Postfix need read access to the aliases.db file - Mailman like to be owner of those files and the Mailman group needs write access to them I. Postfix needs a read access to the aliases.db file We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664 II. Mailman group needs a write access to those files at any time The following behavior has been observed: When creating a new list on command line, using bin/newlist script as follow: # newlist -u virtualhost foobar the files will be created as follow: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db The same thing has been observed when recreating the file from scratch using bin/genaliases: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db Note that in both cases, files were not present. Thus, they were created from scratch. As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file. The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions). That is really a problem. Of course, one can just pre-create the files as follow: # cd /var/lib/ma
[Bug 1696066] [NEW] Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
Public bug reported: Dear project leader At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch. Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map. In order, the following conditions have to be met: - Postfix need read access to the aliases.db file - Mailman like to be owner of those files and the Mailman group needs write access to them I. Postfix needs a read access to the aliases.db file We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664 II. Mailman group needs a write access to those files at any time The following behavior has been observed: When creating a new list on command line, using bin/newlist script as follow: # newlist -u virtualhost foobar the files will be created as follow: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db The same thing has been observed when recreating the file from scratch using bin/genaliases: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db Note that in both cases, files were not present. Thus, they were created from scratch. As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file. The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions). That is really a problem. Of course, one can just pre-create the files as follow: # cd /var/lib/mailman # sg list -c "touch data/aliases && postalias data/aliases" # chmod 0660 data/aliases* but that seem tedious. What if at some point (for any reason), the files get recreated from scratch? So, from my point of view, the MTA/Postfix.py module should always set correct permissions on resulting *.db file, after running POSTALIAS(1) command to be sure that Mailman group has write permissions, at least when the files are created from scratch. Thank you. ** Affects: mailman Importance: Undecided Status: New ** Affects: mailman (Ubuntu) Importance: Undecided Status: New ** Affects: mailman (Debian) Importance: Undecided Status: New ** Description changed: Dear project leader At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these file get created from scratch and which I describe below for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map. In order, the following conditions have to be meet: - Postfix need read access to the aliases.db file - Mailman like to be owner of those files and the Mailman group needs write access to them I. Postfix need read access to the aliases.db file We can either set permissions as 0660 and add postfix user to mailman group or set the permissions as 0664 II. Mailman group need write access to those files at any time Currently, the following behavior has been observed. - When creating a new list on command line, using newlist as follow: '# - newlist -u virtualhost foobar', the files will be created as follow + When creating a new list on command line, using newlist script as + follow: + + # newlist -u virtualhost foobar + + the files will be created as follow: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db The same thing has been observed when recreating the file from scratch - using bin/genaliases + using bin/genaliases: -rw-rw 1 root list aliases -rw-r- 1 root list aliases.db - Note that in both case, files were not present. Thus, they were created + Note that in both cases, files were not present. Thus, they were created from scratch. As you can see here, the Mailman data/aliases table is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file. The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions). That is really a problem. Of course, one can just pre-create the files as fo
[Bug 1695610] Re: Test missing in lists_lists leading to wrong listing when using -V option
** Also affects: mailman (Ubuntu) Importance: Undecided Status: New ** Also affects: mailman (Debian) Importance: Undecided Status: New ** Description changed: Dear project leader, When we list the lists for specific virtualhost, a wrong result can be printed-out in the following condition: - Let's say we have somme lists hosted on bbox.nuxwin.com domain and other - lists on the lists.bbox.nuxwin.com virtualhost. Then, when running - list_lists as follow: + Let's say we have somme lists hosted on bbox.nuxwin.com virtualhost and + other lists on the lists.bbox.nuxwin.com virtualhost. Then, when + running list_lists as follow: list_lists -b -V bbox.nuxwin.com We get also the lists names from the lists.bbox.nuxwin.com virtualhost which is an unexpected behavior. This is due to the fact that you're using find() only. Real use case: # Expected result: root@devuan:~# /usr/lib/mailman/bin/list_lists -b -V lists.bbox.nuxwin.com - foobar - release + foo + bar # Unexpected result: root@devuan:~# /usr/lib/mailman/bin/list_lists -b -V bbox.nuxwin.com - foobar - mailman - release + foo + bar # Unexpected result: root@devuan:~# /usr/lib/mailman/bin/list_lists -b -V nuxwin.com - foobar - mailman - release + foo + bar # Unexpected result: root@devuan:~# /usr/lib/mailman/bin/list_lists -b -V com - foobar - mailman - release + foo + bar # Unexpected result: root@devuan:~# /usr/lib/mailman/bin/list_lists -b -V m - foobar - mailman - release + foo + bar Thank you. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1695610 Title: Test missing in lists_lists leading to wrong listing when using -V option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1694384] Re: Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman
@Mark Sapiro Thank for your answer and the fix ;) That is much appreciated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694384 Title: Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1694384/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1694384] Re: Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman
** Summary changed: - Missing list owner email alias in data/virtual-mailman + Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694384 Title: Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1694384/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1694384] [NEW] Missing list owner email alias in data/virtual-mailman
Public bug reported: Dear project leader, In the Mailman version 2.1.21, you released a fix regarding Mailman- Postfix: - Mailman-Postfix integration will now add mailman@domain entries in data/virtual-mailman for each domain in POSTFIX_STYLE_VIRTUAL_DOMAINS which is a host_name of a list. This is so the addresses which are exposed on admin and listinfo overview pages of virtual domains will be deliverable. (LP: #1459236) That fix was a good thing. However there is an identical problem for the site list owner email that is exposed in email notification when you create a new list. Indeed, when you create a new list, there is a notification that is sent to the list owner and which state that it must address all questions to mailman-owner@VIRTUAL_DOMAIN. Therefore, you should considere adding that alias too in the data/virtual-mailman map. Right now, sending mail to such address result to non-delivery. That being said, I would want give you my personal point of view regarding the email addresses that are exposed. Regarding the site list address that is exposed in the listinfo overview page: I tend to think that exposing the site list email address in the listinfo overview page is a mistake. End-users that visit or subscribe to the lists shouldn't have to ask any question to the mailman site list administrator. Think of a shared hosting environment where there is the sysadmin and the end-users which are administrators of their own lists. Here, my thinking is that subscribers (or visitors) of the listinfo interface should ask their questions, not to the mailman site list administrator, but to the list administrator which is not always the same person. From my point of view, only the list administrators should have to ask something to the mailman site list administrator (sysadmin). Another thing: In the listinfo oveview page, you're also exposing the list administrator personal email in the footer (email used while creating the list). From my point of view, that email should be hidden from the visitors and subscribers. That email, always from my point of view, should be replaced by the list owner email address (-owner@VIRTUAL_DOMAIN). Thank you. ** Affects: mailman Importance: Undecided Status: New ** Affects: mailman (Ubuntu) Importance: Undecided Status: New ** Affects: mailman (Debian) Importance: Undecided Status: New ** Description changed: Dear project leader, In the Mailman version 2.1.21, you released a fix regarding Mailman- Postfix: - - Mailman-Postfix integration will now add mailman@domain entries in - data/virtual-mailman for each domain in POSTFIX_STYLE_VIRTUAL_DOMAINS - which is a host_name of a list. This is so the addresses which are - exposed on admin and listinfo overview pages of virtual domains will - be deliverable. (LP: #1459236) + - Mailman-Postfix integration will now add mailman@domain entries in + data/virtual-mailman for each domain in POSTFIX_STYLE_VIRTUAL_DOMAINS + which is a host_name of a list. This is so the addresses which are + exposed on admin and listinfo overview pages of virtual domains will + be deliverable. (LP: #1459236) - That fix was a good thing. However there is an identical problem for the site list owner email that is exposed in email notification when you create a new list. Indeed, - when you create a new list, there is a notification that is sent to the list owner and which state that it must address all questions to mailman-owner@VIRTUAL_DOMAIN. Therefore, you should considere adding that alias too in the virtual-mailman map. Right now, sending mail to such address result to non-delivery notification. + That fix was a good thing. However there is an identical problem for the + site list owner email that is exposed in email notification when you + create a new list. Indeed, when you create a new list, there is a + notification that is sent to the list owner and which state that it must + address all questions to mailman-owner@VIRTUAL_DOMAIN. Therefore, you + should considere adding that alias too in the virtual-mailman map. Right + now, sending mail to such address result to non-delivery notification. That being said, I would want give you my personal point of view regarding the email addresses that are exposed. Regarding the site list address that is exposed in the listinfo overview page: I tend to think that exposing the site list email address in the listinfo overview page is a mistake. End-users that visit or subscribe to the lists shouldn't have to ask any question to the mailman site list administrator. Think of a shared hosting environment where there is the sysadmin and end-users which are administrators of their own lists. Here, my thinking is that subscribers (or visitors) of the listinfo interface should ask their questions, not to the mailman site li
[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
Both mysql-server-5.5 and mysql-server-5.6 packages (e.g. under Trusty Thar) provide a sysvinit script and an upstart job for mysql. The problem here is that the maintainer has a very strange approach: 1. The sysvinit script links are symply removed in the postinstall script using update-rc.d 2.The sysvinit script doesn't respects Debian policy section 9.11.1 which states that the sysvinit scripts should abort when an upstart job is provided (As I know, Ubuntu has choosen to follow Debian policy regarding cooexistence of upstart jobs and sysvinit scripts) So yes, this situation can lead to several problems. Anybody that run the mysql sysvinit script directly (/etc/init.d/mysql) instead of using service mysql will have problems. Also, if the upstart job is present, and if the sysvninit script is enabled (sysvinit script links created), the mysql socket will be missing on reboot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1326428] Re: clash of upstart and sysvinit scripts
*** This bug is a duplicate of bug 1273462 *** https://bugs.launchpad.net/bugs/1273462 To be more clear: Both mysql-server-5.5 and mysql-server-5.6 packages (e.g. under Trusty Thar) provide a sysvinit script and an upstart job for mysql. The problem here is that the maintainer has a very strange approach: 1. The sysvinit script links are symply removed in the postinstall script using update-rc.d 2.The sysvinit script doesn't respects Debian policy section 9.11.1 which states that the sysvinit scripts should abort when an upstart job is provided (As I know, Ubuntu has choosen to follow Debian policy regarding cooexistence of upstart jobs and sysvinit scripts) So yes, this situation can lead to several problems. Anybody that run the mysql sysvinit script directly (/etc/init.d/mysql) instead of using service mysql will have problems. Also, if the upstart job is present, and if the sysvninit script is enabled (sysvinit script links created), the mysql socket will be missing on reboot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1326428 Title: clash of upstart and sysvinit scripts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1326428/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1542174] Re: Could not install / Could not start service
Seem fixed by: courier-authlib (0.66.4-3) unstable; urgency=medium * Check and create courier user in authdaemon package in case courier-base is not installed first (LP#1542174) -- Ondřej Surý Fri, 05 Feb 2016 09:58:26 +0100 But a question still remains there: Why create the 'courier' user while the 'daemon' user has been used for years... Really strange. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1542174 Title: Could not install / Could not start service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/1542174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1542174] Re: Could not install / Could not start service
More details: # root@xenial:/usr/local/src/imscp# LANG=C aptitude install courier-authdaemon The following NEW packages will be installed: courier-authdaemon 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/5756 B of archives. After unpacking 39.9 kB will be used. Selecting previously unselected package courier-authdaemon. (Reading database ... 101286 files and directories currently installed.) Preparing to unpack .../courier-authdaemon_0.66.4-2_amd64.deb ... Unpacking courier-authdaemon (0.66.4-2) ... Processing triggers for systemd (228-5ubuntu3) ... Processing triggers for ureadahead (0.100.0-19) ... Setting up courier-authdaemon (0.66.4-2) ... [/usr/lib/tmpfiles.d/courier-authdaemon.conf:2] Unknown user 'courier'. Job for courier-authdaemon.service failed because the control process exited with error code. See "systemctl status courier-authdaemon.service" and "journalctl -xe" for details. invoke-rc.d: initscript courier-authdaemon, action "start" failed. dpkg: error processing package courier-authdaemon (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for systemd (228-5ubuntu3) ... Processing triggers for ureadahead (0.100.0-19) ... Errors were encountered while processing: courier-authdaemon E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up courier-authdaemon (0.66.4-2) ... [/usr/lib/tmpfiles.d/courier-authdaemon.conf:2] Unknown user 'courier'. Job for courier-authdaemon.service failed because the control process exited with error code. See "systemctl status courier-authdaemon.service" and "journalctl -xe" for details. invoke-rc.d: initscript courier-authdaemon, action "start" failed. dpkg: error processing package courier-authdaemon (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: courier-authdaemon # As you can see, installation failed. This is due to the wrong user/group put in the /usr/lib/tmpfiles.d/courier-authdaemon.conf: # root@xenial:/usr/local/src/imscp# cat /usr/lib/tmpfiles.d/courier-authdaemon.conf #Type PathMode UID GID Age Argument d /var/run/courier/authdaemon 0755 courier courier - - # Changing it to daemon user/group solve the problem: # root@xenial:/usr/local/src/imscp# nano /usr/lib/tmpfiles.d/courier-authdaemon.conf root@xenial:/usr/local/src/imscp# cat /usr/lib/tmpfiles.d/courier-authdaemon.conf #Type PathMode UID GID Age Argument d /var/run/courier/authdaemon 0755 daemon daemon - - root@xenial:/usr/local/src/imscp# apt-get install -f Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait 0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. 1 partiellement installés ou enlevés. Après cette opération, 0 o d'espace disque supplémentaires seront utilisés. Paramétrage de courier-authdaemon (0.66.4-2) ... root@xenial:/usr/local/src/imscp# # -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1542174 Title: Could not install / Could not start service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/1542174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1542174] Re: Could not install / Could not start service
@ Ondřej Surý Loving when you push changes without any test... You should be killed. courier-authlib (0.66.4-2) unstable; urgency=medium * Convert the d/copyright into machine-readable file and add license for authldaplib.c * Use invoke-rc.d to restart authdaemon on mysql and postgresql fresh installation * Add courier-authdaemon systemd files (service and tmpfile) -- Ondřej Surý Sat, 02 Jan 2016 17:29:17 +0100 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1542174 Title: Could not install / Could not start service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/1542174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1542174] [NEW] Could not install / Could not start service
Public bug reported: Latest version of the courier-authdaemon package as provided in Ubuntu Xenial repository cannot be installed due to the following bug: The 'courier' user/group in the /usr/lib/tmpfiles.d/courier- authdaemon.conf file doesn't exists. It should be replaced by the 'daemon' user/group. Once I've edited the file manually for changing the user/group and run apt-get install -f, the package was successfully installed. INFO: root@xenial:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Xenial Xerus (development branch) Release:16.04 Codename: xenial root@xenial:~# aptitude show courier-authdaemon Paquet : courier-authdaemon État: installé Automatiquement installé: oui Version : 0.66.4-2 Priorité : optionnel Section : universe/mail Responsable : Ubuntu Developers Architecture : amd64 Taille décompressée : 39,9 k Dépend: courier-authlib (>= 0.66.4), lsb-base (>= 3.0-10) Est en conflit: courier-authdaemon:i386 Description : Démon d'authentification pour Courier Ce paquet contient le démon d'authentification pour les applications Courier. Site : http://www.courier-mta.org/ ** Affects: courier-authlib (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1542174 Title: Could not install / Could not start service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/1542174/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1002510] Re: package courier-authlib-mysql 0.63.0-3.1ubuntu1 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1
Same here. Upgrade failed on xenial. Well, to fix the problem, I've created the expected file manually and run apt-get install -f. Once done, I've purged the package and reinstalled it. Then installation failed because the service authdaemon could not start. This is due to the new systemd /usr/lib/tmpfiles.d /courier-authdaemon.conf configuration file which attemps to create run directory with wrong user (courier) instead of the daemon user. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1002510 Title: package courier-authlib-mysql 0.63.0-3.1ubuntu1 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/courier-authlib/+bug/1002510/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1538284] Re: Unescaped left brace in regex is deprecated
Wrong package reported. The right package is libpam-runtime root@xenial:/usr/local/src/imscp# LANG=C aptitude show libpam-runtime Package: libpam-runtime State: installed Automatically installed: no Multi-Arch: foreign Version: 1.1.8-3.1ubuntu3 Priority: required Section: admin Maintainer: Ubuntu Developers Architecture: all Uncompressed Size: 307 k Depends: debconf (>= 0.5) | debconf-2.0, debconf (>= 1.5.19) | cdebconf, libpam-modules (>= 1.0.1-6) Conflicts: libpam0g-util Replaces: libpam0g-dev, libpam0g-util, libpam0g-dev:i386 Provides: libpam-runtime:i386 (= 1.1.8-3.1ubuntu3) Description: Runtime support for the PAM library Contains configuration files and directories required for authentication to work on Debian systems. This package is required on almost all installations. Homepage: http://pam.sourceforge.net/ ** Tags added: libpam-runtime ** Also affects: pam (Ubuntu) Importance: Undecided Status: New ** No longer affects: postgresql-9.5 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1538284 Title: Unescaped left brace in regex is deprecated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1538284/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1538284] [NEW] Unescaped left brace in regex is deprecated
Public bug reported: When installing postgresql on Ubuntu 16.04 (xenial), the following warning are raised: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/(?https://bugs.launchpad.net/bugs/1538284 Title: Unescaped left brace in regex is deprecated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postgresql-9.5/+bug/1538284/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1242376] Re: "reload php5-fpm" crashes
I agreed totally with Renan... PHP5-FPM reload is broken meaning that restart is mandatory ATM (which is not a way to go for shared hosting environment where configuration should be reloaded without having to do a full restart)... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1242376 Title: "reload php5-fpm" crashes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1242376/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 759974] Re: PHP Fatal error: Class 'PEAR' not found in /usr/share/roundcube/program/include/iniset.php on line 132
Hello community ; I've encountered an identical problem on Ubuntu 12.4. To solve it, I've only un-commented the include_path parameter (include_path = ".:/usr/share/php") into the /etc/php5/apache2/php.ini and restarted the apache2 service. cheers -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/759974 Title: PHP Fatal error: Class 'PEAR' not found in /usr/share/roundcube/program/include/iniset.php on line 132 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/roundcube/+bug/759974/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs