[Bug 1566519] Re: Please add native systemd units

2018-01-08 Thread Nish Aravamudan 
This was fixed in Debian in 2.4.23-5, which is in Zesty+.

** Changed in: apache2 (Ubuntu)
   Status: Triaged => Fix Released

-- 
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/1566519

Title:
  Please add native systemd units

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1566519/+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

Re: [Bug 1740892] Re: corosync upgrade on 2018-01-02 caused pacemaker to fail

2018-01-08 Thread Nish Aravamudan 
On Mon, Jan 8, 2018 at 8:48 AM, Victor Tapia  wrote:
> As mentioned by Mario @ #10, stopping corosync while pacemaker runs
> throws the same error as the upgrade. Syslog from Xenial +
> corosync=2.3.5-3ubuntu1:
>
> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopping Pacemaker High 
> Availability Cluster Manager...
> Jan  8 16:24:37 xenial-corosync pacemakerd[28747]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: State transition 
> S_IDLE -> S_POLICY_ENGINE [ input=I_SHUTDOWN cause=C_SHUTDOWN 
> origin=crm_shutdown ]
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Delaying fencing 
> operations until there are resources to manage
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Scheduling Node 
> xenial-corosync for shutdown
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Calculated 
> Transition 1: /var/lib/pacemaker/pengine/pe-input-52.bz2
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Transition 1 
> (Complete=1, Pending=0, Fired=0, Skipped=0, Incomplete=0, 
> Source=/var/lib/pacemaker/pengine/pe-input-52.bz2): Complete
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync cib[28748]:  warning: new_event_notification 
> (28748-28753-12): Broken pipe (32)
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync attrd[28751]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync lrmd[28750]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync stonith-ng[28749]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopped Pacemaker High 
> Availability Cluster Manager.
>
>
> Pacemakerd shuts down sending SIGTERM to its components, but after the 
> install, corosync does not start pacemaker. BTW, "systemctl restart corosync" 
> restarts both services perfectly
>
> I think that the option A from James Page (#11) is the way to go

Hrm, sorry, the above isn't exactly what is relevant here. That is, if
you only issued  stop on corosync, then the above is fully correct
(and I'm not seeing the 'same' error you mention (which would be about
the library or so).

It is fully correct based upon the unit files that if you issue
`systemctl stop corosync` that you will see in the logs that pacemaker
is stopped first (the last line above shows this happening). It is not
expected that stopping corosync would cause pacemaker to restart.

If you, in the above env, issue `systemctl start corosync`, does
pacemaker start? Here is what I see in a Xenial LXD:

root@splendid-viper:~# systemctl status corosync
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled;
vendor preset: enabled)
   Active: active (running) since Mon 2018-01-08 18:23:34 UTC; 18s ago
 Main PID: 3619 (corosync)
Tasks: 2
   Memory: 42.8M
  CPU: 329ms
   CGroup: /system.slice/corosync.service
   └─3619 /usr/sbin/corosync -f

Jan 08 18:23:34 splendid-viper corosync[3619]:   [TOTEM ] Initializing
transport (UDP/IP Multicast).
Jan 08 18:23:34 splendid-viper corosync[3619]:   [TOTEM ] Initializing
transmit/receive security (NSS) crypto: none hash: none
Jan 08 18:23:34 splendid-viper corosync[3619]:   [TOTEM ] The network
interface [127.0.0.1] is now up.
Jan 08 18:23:34 splendid-viper corosync[3619]:   [QB] server name: cmap
Jan 08 18:23:34 splendid-viper corosync[3619]:   [QB] server name: cfg
Jan 08 18:23:34 splendid-viper corosync[3619]:   [QB] server name: cpg
Jan 08 18:23:34 splendid-viper corosync[3619]:   [QB] server name:
votequorum
Jan 08 18:23:34 splendid-viper corosync[3619]:   [QB] server name: quorum
Jan 08 18:23:34 splendid-viper corosync[3619]:   [TOTEM ] A new
membership (127.0.0.1:16) was formed. Members joined: 2130706433
Jan 08 18:23:34 splendid-viper systemd[1]: Started Corosync Cluster Engine.
root@splendid-viper:~# systemctl restart corosync
root@splendid-viper:~# systemctl status corosync
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled;
vendor preset: enabled)
   Active: active (running) since Mon 2018-01-08 18:24:10 UTC; 15s ago
 Main PID: 3640 (corosync)
Tasks: 2
   Memory: 42.1M
  CPU: 263ms
   CGroup: /system.slice/corosync.service
   └─3640 /usr/sbin/corosync -f

Jan 08 18:24:10

Re: [Bug 1740892] Re: corosync upgrade on 2018-01-02 caused pacemaker to fail

2018-01-08 Thread Nish Aravamudan 
On Mon, Jan 8, 2018 at 10:04 AM, Nish Aravamudan
 wrote:
> On Mon, Jan 8, 2018 at 9:51 AM, Nish Aravamudan
>  wrote:
>> On Mon, Jan 8, 2018 at 8:48 AM, Victor Tapia  
>> wrote:
>>> As mentioned by Mario @ #10, stopping corosync while pacemaker runs
>>> throws the same error as the upgrade. Syslog from Xenial +
>>> corosync=2.3.5-3ubuntu1:
>>>
>>> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopping Pacemaker High 
>>> Availability Cluster Manager...
>>> Jan  8 16:24:37 xenial-corosync pacemakerd[28747]:   notice: Invoking 
>>> handler for signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Invoking handler for 
>>> signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: State transition 
>>> S_IDLE -> S_POLICY_ENGINE [ input=I_SHUTDOWN cause=C_SHUTDOWN 
>>> origin=crm_shutdown ]
>>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Delaying fencing 
>>> operations until there are resources to manage
>>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Scheduling Node 
>>> xenial-corosync for shutdown
>>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Calculated 
>>> Transition 1: /var/lib/pacemaker/pengine/pe-input-52.bz2
>>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Transition 1 
>>> (Complete=1, Pending=0, Fired=0, Skipped=0, Incomplete=0, 
>>> Source=/var/lib/pacemaker/pengine/pe-input-52.bz2): Complete
>>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Disconnecting from 
>>> Corosync
>>> Jan  8 16:24:37 xenial-corosync cib[28748]:  warning: 
>>> new_event_notification (28748-28753-12): Broken pipe (32)
>>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Invoking handler 
>>> for signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync attrd[28751]:   notice: Invoking handler 
>>> for signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync lrmd[28750]:   notice: Invoking handler for 
>>> signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync stonith-ng[28749]:   notice: Invoking 
>>> handler for signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Invoking handler for 
>>> signal 15: Terminated
>>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
>>> Corosync
>>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
>>> Corosync
>>> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopped Pacemaker High 
>>> Availability Cluster Manager.
>>>
>>>
>>> Pacemakerd shuts down sending SIGTERM to its components, but after the 
>>> install, corosync does not start pacemaker. BTW, "systemctl restart 
>>> corosync" restarts both services perfectly
>>>
>>> I think that the option A from James Page (#11) is the way to go
>>
>> I took a quick look at a LXD container after seeing Felipe and
>> Victor's posts. It seems like this is a bug in the xenial (at least)
>> systemd unit files:
>>
>> # grep pacemaker /lib/systemd/system/corosync.service
>> #  pacemaker.service, and if you want to exert the watchdog when a
>>
>> # grep corosync /lib/systemd/system/pacemaker.service
>> After=corosync.service
>> Requires=corosync.service
>> # ExecStopPost=/bin/sh -c 'pidof crmd || killall -TERM corosync'
>>
>> So, what I see is that corosync.service has no dependency on
>> pacemaker.service (in the file).
>>
>> pacemaker.service will start after corosync.service. And when
>> pacemaker.service is shutdown it will be before corosync.service.
>> Additionally, if pacemaker.service is started, then corosync.service
>> is started as well.
>>
>> Note, nothing specifies what Felipe said -- there is no guarantee that
>> pacemaker is started, restarted, etc. when corosync is.
>>
>> I think the next step is to look at Bionic's systemd services
>> (probably newer) or upstream's and see if there is a difference, or
>> new dependencies added there.
>
> Or perhaps ask upstream what they think is providing this assurance in
> their systemd files, because I'm not seeing it.
>
> If we have a hard dependency between pacemaker and corosync, then I
> think we might need a PartOf directive, in order to ensure they are
> always following the state transitions together.

Or if that is bad (because it does feel like a layering violation and
maybe it makes sense to have either pacemaker or corosync installed
with the other), the pacemaker.service should says

WantedBy=corosync.service

That will ensure that when corosync.service starts, pacemaker.service
starts. The Requires line ensures that when corosync.service stops,
pacemaker stops (with the order specified by the After).

I think :)

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1740892

Title:
  corosync upgrade on 2018-01-02 caused pacemaker to fail

To manage notifications about this bug go to:

Re: [Bug 1740892] Re: corosync upgrade on 2018-01-02 caused pacemaker to fail

2018-01-08 Thread Nish Aravamudan 
On Mon, Jan 8, 2018 at 9:51 AM, Nish Aravamudan
 wrote:
> On Mon, Jan 8, 2018 at 8:48 AM, Victor Tapia  
> wrote:
>> As mentioned by Mario @ #10, stopping corosync while pacemaker runs
>> throws the same error as the upgrade. Syslog from Xenial +
>> corosync=2.3.5-3ubuntu1:
>>
>> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopping Pacemaker High 
>> Availability Cluster Manager...
>> Jan  8 16:24:37 xenial-corosync pacemakerd[28747]:   notice: Invoking 
>> handler for signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Invoking handler for 
>> signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: State transition 
>> S_IDLE -> S_POLICY_ENGINE [ input=I_SHUTDOWN cause=C_SHUTDOWN 
>> origin=crm_shutdown ]
>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Delaying fencing 
>> operations until there are resources to manage
>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Scheduling Node 
>> xenial-corosync for shutdown
>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Calculated 
>> Transition 1: /var/lib/pacemaker/pengine/pe-input-52.bz2
>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Transition 1 
>> (Complete=1, Pending=0, Fired=0, Skipped=0, Incomplete=0, 
>> Source=/var/lib/pacemaker/pengine/pe-input-52.bz2): Complete
>> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Disconnecting from 
>> Corosync
>> Jan  8 16:24:37 xenial-corosync cib[28748]:  warning: new_event_notification 
>> (28748-28753-12): Broken pipe (32)
>> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Invoking handler 
>> for signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync attrd[28751]:   notice: Invoking handler for 
>> signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync lrmd[28750]:   notice: Invoking handler for 
>> signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync stonith-ng[28749]:   notice: Invoking 
>> handler for signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Invoking handler for 
>> signal 15: Terminated
>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
>> Corosync
>> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
>> Corosync
>> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopped Pacemaker High 
>> Availability Cluster Manager.
>>
>>
>> Pacemakerd shuts down sending SIGTERM to its components, but after the 
>> install, corosync does not start pacemaker. BTW, "systemctl restart 
>> corosync" restarts both services perfectly
>>
>> I think that the option A from James Page (#11) is the way to go
>
> I took a quick look at a LXD container after seeing Felipe and
> Victor's posts. It seems like this is a bug in the xenial (at least)
> systemd unit files:
>
> # grep pacemaker /lib/systemd/system/corosync.service
> #  pacemaker.service, and if you want to exert the watchdog when a
>
> # grep corosync /lib/systemd/system/pacemaker.service
> After=corosync.service
> Requires=corosync.service
> # ExecStopPost=/bin/sh -c 'pidof crmd || killall -TERM corosync'
>
> So, what I see is that corosync.service has no dependency on
> pacemaker.service (in the file).
>
> pacemaker.service will start after corosync.service. And when
> pacemaker.service is shutdown it will be before corosync.service.
> Additionally, if pacemaker.service is started, then corosync.service
> is started as well.
>
> Note, nothing specifies what Felipe said -- there is no guarantee that
> pacemaker is started, restarted, etc. when corosync is.
>
> I think the next step is to look at Bionic's systemd services
> (probably newer) or upstream's and see if there is a difference, or
> new dependencies added there.

Or perhaps ask upstream what they think is providing this assurance in
their systemd files, because I'm not seeing it.

If we have a hard dependency between pacemaker and corosync, then I
think we might need a PartOf directive, in order to ensure they are
always following the state transitions together.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1740892

Title:
  corosync upgrade on 2018-01-02 caused pacemaker to fail

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1740892/+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

Re: [Bug 1740892] Re: corosync upgrade on 2018-01-02 caused pacemaker to fail

2018-01-08 Thread Nish Aravamudan 
On Mon, Jan 8, 2018 at 8:48 AM, Victor Tapia  wrote:
> As mentioned by Mario @ #10, stopping corosync while pacemaker runs
> throws the same error as the upgrade. Syslog from Xenial +
> corosync=2.3.5-3ubuntu1:
>
> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopping Pacemaker High 
> Availability Cluster Manager...
> Jan  8 16:24:37 xenial-corosync pacemakerd[28747]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: State transition 
> S_IDLE -> S_POLICY_ENGINE [ input=I_SHUTDOWN cause=C_SHUTDOWN 
> origin=crm_shutdown ]
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Delaying fencing 
> operations until there are resources to manage
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Scheduling Node 
> xenial-corosync for shutdown
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Calculated 
> Transition 1: /var/lib/pacemaker/pengine/pe-input-52.bz2
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Transition 1 
> (Complete=1, Pending=0, Fired=0, Skipped=0, Incomplete=0, 
> Source=/var/lib/pacemaker/pengine/pe-input-52.bz2): Complete
> Jan  8 16:24:37 xenial-corosync crmd[28753]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync cib[28748]:  warning: new_event_notification 
> (28748-28753-12): Broken pipe (32)
> Jan  8 16:24:37 xenial-corosync pengine[28752]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync attrd[28751]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync lrmd[28750]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync stonith-ng[28749]:   notice: Invoking handler 
> for signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Invoking handler for 
> signal 15: Terminated
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync cib[28748]:   notice: Disconnecting from 
> Corosync
> Jan  8 16:24:37 xenial-corosync systemd[1]: Stopped Pacemaker High 
> Availability Cluster Manager.
>
>
> Pacemakerd shuts down sending SIGTERM to its components, but after the 
> install, corosync does not start pacemaker. BTW, "systemctl restart corosync" 
> restarts both services perfectly
>
> I think that the option A from James Page (#11) is the way to go

I took a quick look at a LXD container after seeing Felipe and
Victor's posts. It seems like this is a bug in the xenial (at least)
systemd unit files:

# grep pacemaker /lib/systemd/system/corosync.service
#  pacemaker.service, and if you want to exert the watchdog when a

# grep corosync /lib/systemd/system/pacemaker.service
After=corosync.service
Requires=corosync.service
# ExecStopPost=/bin/sh -c 'pidof crmd || killall -TERM corosync'

So, what I see is that corosync.service has no dependency on
pacemaker.service (in the file).

pacemaker.service will start after corosync.service. And when
pacemaker.service is shutdown it will be before corosync.service.
Additionally, if pacemaker.service is started, then corosync.service
is started as well.

Note, nothing specifies what Felipe said -- there is no guarantee that
pacemaker is started, restarted, etc. when corosync is.

I think the next step is to look at Bionic's systemd services
(probably newer) or upstream's and see if there is a difference, or
new dependencies added there.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1740892

Title:
  corosync upgrade on 2018-01-02 caused pacemaker to fail

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1740892/+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 1708665] Re: prerotate.sh fails due to no shell for www-data user

2018-01-08 Thread Andreas Hasenack 
** Also affects: awstats (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858461
   Importance: Unknown
   Status: Unknown

-- 
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/1708665

Title:
  prerotate.sh fails due to no shell for www-data user

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/awstats/+bug/1708665/+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 1740892] Re: corosync upgrade on 2018-01-02 caused pacemaker to fail

2018-01-08 Thread James Page 
Based on #10 and some testing I did early today, it really feels like
this might be a bug in pacemaker when re-connecting to corosync after a
restart; I think there are two ways forward on this:

a) corosync package updates should always restart pacemaker
b) we should look for a fix in pacemaker to make it more resilient to corosync 
restarts

either would have prevented this issue from occurring in the first
place.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pacemaker in Ubuntu.
https://bugs.launchpad.net/bugs/1740892

Title:
  corosync upgrade on 2018-01-02 caused pacemaker to fail

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-hacluster/+bug/1740892/+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 1741227] Re: apparmor denial to several paths to binaries

2018-01-08 Thread Andreas Hasenack 
** Changed in: ntp (Ubuntu)
 Assignee: (unassigned) => ChristianEhrhardt (paelzer)

** Changed in: ntp (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1741227

Title:
  apparmor denial to several paths to binaries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1741227/+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 1576799] Re: Regression: 2:4.3.8+dfsg-0ubuntu0.14.04.2 Failed to Issue the StartTLS instruction

2018-01-08 Thread Andreas Hasenack 
Please run the command from comment #27, it will help diagnose why you
didn't get my PPA packages.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1576799

Title:
  Regression: 2:4.3.8+dfsg-0ubuntu0.14.04.2 Failed to Issue the StartTLS
  instruction

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1576799/+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 1658273] Re: Failed to preset unit: Unit file /etc/systemd/system/samba-ad-dc.service is masked.

2018-01-08 Thread Andreas Hasenack 
It is indeed confusing, I totally agree.

Maybe we should morph this bug into that issue only. Something like
"confusing error message when not configured as AD/DC"

-- 
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/1658273

Title:
  Failed to preset unit: Unit file /etc/systemd/system/samba-ad-
  dc.service is masked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1658273/+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 1576799] Re: Regression: 2:4.3.8+dfsg-0ubuntu0.14.04.2 Failed to Issue the StartTLS instruction

2018-01-08 Thread Andreas Hasenack 
Can you please check which versions of samba you have available, and
from where, with the following command:

apt-cache policy samba

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1576799

Title:
  Regression: 2:4.3.8+dfsg-0ubuntu0.14.04.2 Failed to Issue the StartTLS
  instruction

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1576799/+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