[Bug 1683229] Re: package mariadb-server-10.1 failed to install since mysql-server-5.7 isn't purged

[Laurent Declercq]

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

[Laurent Declercq]

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)

[Laurent Declercq]

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

[Laurent Declercq]

@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

[Laurent Declercq]

@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

[Laurent Declercq]

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

[Laurent Declercq]

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

[Laurent Declercq]

@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

[Laurent Declercq]

** 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

[Laurent Declercq]

** 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 

[Bug 1696066] [NEW] Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files

[Laurent Declercq]

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 

[Bug 1695610] Re: Test missing in lists_lists leading to wrong listing when using -V option

[Laurent Declercq]

** 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

[Laurent Declercq]

@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

[Laurent Declercq]

** 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

[Laurent Declercq]

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 

[Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

[Laurent Declercq]

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 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists

[Laurent Declercq]

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
Server Team, which is subscribed to the bug report.
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-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 1326428] Re: clash of upstart and sysvinit scripts

[Laurent Declercq]

*** 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
Server Team, which is subscribed to mysql-5.6 in 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-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 1326428] Re: clash of upstart and sysvinit scripts

[Laurent Declercq]

*** 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

[Laurent Declercq]

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

[Laurent Declercq]

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] [NEW] Could not install / Could not start service

[Laurent Declercq]

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 1542174] Re: Could not install / Could not start service

[Laurent Declercq]

@ 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 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

[Laurent Declercq]

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

[Laurent Declercq]

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

[Laurent Declercq]

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

[Laurent Declercq]

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
Server Team, which is subscribed to php5 in 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-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 1242376] Re: reload php5-fpm crashes

[Laurent Declercq]

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

[Laurent Declercq]

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