On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
> The abstraction is meant to cover the client, not systemd internal
> specifics. A client simply accessing that DBus API won't need it and a
> client simply accessing those sockets won't need it. It very well might
> be that a profiled application
@jdstrand, asked in #systemd about @{PROC}/sys/kernel/random/boot_id and
didn't get much information back. That said,
https://github.com/systemd/systemd/blob/master/docs/RANDOM_SEEDS.md
#systemds-use-of-random-numbers says:
> At various places systemd needs random bytes for temporary file name
@narchetic, I did not notice any slowdown during shutdown but those
servers are headless and I didn't time their reboot.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863919
Title:
[regression]
On 2020-03-30 4:54 p.m., Seth Arnold wrote:
> Sadly 'journactl -xe' was useless. (It only showed a thousand unrelated
> lines.) A raw journalctl took forever to run long enough to let me see it
> generated two million lines of output, and started about two years ago, that
> I'm not keen on
Thanks for the follow-up.
** Changed in: strongswan (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869710
Title:
charon+apparmor can't run updown
charon's profile includes a local override file that is useful when
using non-default setups. As such, I think the proper solution for you
would be to use this:
echo '/bin/bash rmPUx,' | sudo tee -a
/etc/apparmor.d/local/usr.lib.ipsec.charon
sudo apparmor_parser -rTW
On 2020-03-26 3:54 p.m., Scott Kitterman wrote:
> Does applying this change help:
>
> https://salsa.debian.org/postfix-team/postfix-dev/-/commit/
> b8e0b846e34eeaaa2315ead2304824b21b01fe7a
Does not help.
Sion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
On 2020-03-26 2:40 p.m., Scott Kitterman wrote:
> On Thursday, March 26, 2020 12:22:20 PM EDT you wrote:
>> Comparing strace between Ubuntu and Debian (lxc launch images:debian/10)
>> showed that Debian's version doesn't try to connect to the tlsmgr socket
>> for some reason.
>>
>> Ubuntu
Comparing strace between Ubuntu and Debian (lxc launch images:debian/10)
showed that Debian's version doesn't try to connect to the tlsmgr socket
for some reason.
Ubuntu 3.4.10-1:
# grep connect /tmp/strace | grep AF_UNIX
connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) = -1
As mentioned in LP: #1796911 by xnox, some abstractions should be
augmented with the corresponding dbus rules. Support for userdb should
also be added IMHO.
Here are the rules that were needed in my tests on an up to date Focal:
# systemd DynamicUser
/run/systemd/userdb/ r,
Public bug reported:
systemd offers to create dynamic (and semi-stable) users for services.
This causes many services using Apparmor profiles to trigger those
denials (even when they don't use the DynamicUser feature):
audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
auid=4294967295
I'm happy to report that apt version 2.0.0 fixed this bug, thanks!
$ apt-cache policy apt
apt:
Installed: 2.0.0
Candidate: 2.0.0
Version table:
*** 2.0.0 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
** Changed in: apt (Ubuntu)
Both the kernel and samba received many fixes since this bug was
reported. As such, are you able to reproduce the issue on a system will
current patches? Setting as incomplete until you can confirm it's still
reproducible. Thanks
** Changed in: samba (Ubuntu)
Status: New => Incomplete
**
Ubuntu 15.10 reached its end of life long ago. Is this issue still
reproducible on a supported release? Setting as incomplete until this is
confirmed, thanks!
** Changed in: samba (Ubuntu)
Status: New => Incomplete
** Changed in: linux-lts-wily (Ubuntu)
Status: New => Incomplete
Public bug reported:
In Focal, running 'apt update' result in the following messages being
logged:
Mar 20 15:24:12 fa1 http[3392]: Libgcrypt warning: missing initialization -
please fix the application
Mar 20 15:24:12 fa1 http[3393]: Libgcrypt warning: missing initialization -
please fix the
The "ExecReload=+/bin/kill" way of reloading without needing extra caps
seems sensible. That said, I'm wondering what's the use case for a
reload instead of a restart as man openvpn(8) describes what happens on
SIGHUP:
SIGNALS
SIGHUP Cause OpenVPN to close all TUN/TAP and network connections,
Public bug reported:
# Steps to reproduce:
$ lxc launch images:ubuntu/focal fa1
$ lxc shell fa1
root@fa1:~# echo 'APT::Sandbox::Seccomp "true";' >
/etc/apt/apt.conf.d/01apt-seccomp
root@fa1:~# rm /var/lib/apt/lists/*Release # makes sure we fetch stuff from
the network
root@fa1:~# apt-get
Public bug reported:
Since the snap upgrade to 80.0.3987.132, chromium keeps complaining
about I/O errors that are apparently due to missing Apparmor rules. Here
is what gets logged by "journalctl -f -o cat" when starting and closing
chromium:
AVC apparmor="DENIED" operation="unlink"
Hello Stefan,
According to the status output, NGINX couldn't start because of this
error:
nginx: [emerg]
BIO_new_file("/etc/letsencrypt/live/mail.distict.de/fullchain.pem")
failed (SSL: error:02001002:system library:fopen:No such file or
This is not 19.04->19.10 specific as no later than yesterday it affected
one of my client. I've reported the 16.04->18.04 bug against php-
defaults as it's the provider of mod_php, see LP: #1865218
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Public bug reported:
Yesterday, when upgrading a client VMs running Xenial and moving to
Bionic, I noticed Apache's mod_php was disabled. I later reproduced this
in a container:
# create a Xenial container
$ lxc launch images:ubuntu/xenial xa
Creating xa
Starting xa
# Install
https://usn.ubuntu.com/4166-2/ provided the fix for 14.04 ESM so all
supported releases are patched. As such, closing.
** Changed in: php-defaults (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Public bug reported:
tl;dr: it would be nice to be able to set environment variable on a per-
snap basis.
I ran into this need when trying to workaround a chrome/chromium bug [1]
where one needs to export MESA_GLSL_CACHE_DISABLE=true when starting the
browser to have the GPU sandbox working.
So this bug will be fixed when snapd's 2.43 SRU goes through. I
appreciate the pointer for the gpu-process sanboxing problem and its
workaround! Many thanks Jalon!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: snap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862262
Title:
[snap] apparmor denials on /sys/devices/virtual/dmi/id/sys_vendor and
product_name
To manage notifications about
Using a single "listen [::]:80 default_server ipv6only=off;" seems to do
the right thing in all situations: IPv4-only, IPv6-only or dual-stack.
The drawback of using this single socket is that IPv4 clients have their
IPs represented as IPv4-Mapped IPv6 in access_log:
==>
Public bug reported:
Since lvm2 was updated to 2.02.176-4.1ubuntu3.18.04.2 on Bionic (LP:
#1854981), we notice that some of our machines have lingering pvscan
processes apparently running from the initramfs's root that
persist/never finish/exit.
On the affected servers, this is visible as there
Public bug reported:
After the automatic upgrade from lxd's snap from 3.20 to 3.21, those
denials appeared:
audit: type=1400 audit(1581974677.106:144): apparmor="DENIED"
operation="open" profile="snap.lxd.hook.configure"
name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=13303
The version in focal-proposed works well, thanks Christian! I hadn't
anticipated the additional roadblocks so I really appreciate you pushing
it forward nevertheless!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tested on various Bionic machines:
The following packages will be upgraded:
apache2 (2.4.29-1ubuntu4.11 => 2.4.29-1ubuntu4.12)
apache2-bin (2.4.29-1ubuntu4.11 => 2.4.29-1ubuntu4.12)
apache2-data (2.4.29-1ubuntu4.11 => 2.4.29-1ubuntu4.12)
apache2-utils (2.4.29-1ubuntu4.11 =>
Public bug reported:
When starting chromium's snap, those messages are logged:
Feb 6 12:34:17 foo kernel: [106190.836260] audit: type=1400
audit(1581010457.097:1372): apparmor="DENIED" operation="open"
profile="snap.chromium.chromium" name="/sys/devices/virtual/dmi/id/sys_vendor"
pid=20044
** Bug watch added: Debian Bug tracker #898307
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898307
** Also affects: squid via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898307
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a
Thanks Robie! I should have mentioned that GnuTLS doesn't make SSL
bumping possible. My request was to enable the compile option in future
releases which is why I did not mention the one I was using.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
In order to do SSL bumping [1], it seems that squid needs to be
configured '--with-openssl'.
Justification/use cases:
Nowadays, HTTPS represents the majority of the traffic and it cannot be
observed as easily as HTTP. With SSL bumping, squid can use the SNI
header that is
While the fix only applies to the client side, you got me questioning
what I had done so I redid the test.
This time it worked with 5.6.2-1ubuntu2.5 on the client side and
5.6.2-1ubuntu2.4 on the server side. I must have forgot to restart
NetworkManager or something stupid like that in my first
** Tags removed: verification-failed verification-failed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1772705
Title:
IKEv2 VPN
It turns out that setting "local: 0.0.0.0" does the right thing.
Working example:
tunnels:
he0:
mode: sit
remote: 192.0.2.1
local: 0.0.0.0
addresses: [ "2001:db8::2/64" ]
gateway6: "2001:db8::1"
** Changed in: netplan.io (Ubuntu)
Status: Confirmed =>
I have the server side configured with ipsec.conf:
config setup
charondebug="ike 0, enc 0, net 0"
conn %default
keyexchange=ikev2
mobike=no
dpddelay=60
dpdtimeout=180
conn lp1772705
left=172.24.26.187
leftcert=peerCert.der
leftauth=pubkey
leftsubnet=8.8.8.8/32
right=%any
On 2019-12-11 12:33 p.m., Rafael David Tinoco wrote:
> For openvpn + systemd-resolve:
>
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.
There's a package for that: openvpn-systemd-resolved
--
You received this
On 2019-12-11 12:33 p.m., Rafael David Tinoco wrote:
> For openvpn + systemd-resolve:
>
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.
There's a package for that: openvpn-systemd-resolved
--
You received this
On Bionic, the stock default sources are using HTTPS:
$ gem environment | grep -A1 'REMOTE SOURCES'
- REMOTE SOURCES:
- https://rubygems.org/
So it's no longer required to create a /etc/gemrc or ~/.gemrc file.
** Changed in: ruby1.9.1 (Ubuntu)
Status: Confirmed => Fix Released
--
> For openvpn + systemd-resolve:
>
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.
There's a package for that: openvpn-systemd-resolved
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
We use apt-cacher-ng configured as apt proxy on every machine and when
trying to upgrade a Xenial machine, I got this:
# do-release-upgrade
Checking for a new Ubuntu release
No new release found.
Running tcpdump showed that do-release-upgrade tried to reach
Please refer to the SRU process
(https://wiki.ubuntu.com/StableReleaseUpdates) regarding package
upgrades.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1855567
Title:
msmtp extremely out of date -
It would be useful if you could include steps to reproduce the problem.
If you also have logs about the failure, please do provide them.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1855567
Title:
FYI, since version 1.8.1-1, the Debian package ships a systemd service to
control msmtpd and it
lets you configure the listening port. In version 1.8.5-1, an init.d script was
added as well. Version 1.8.6-1 is included in the Ubuntu release that's
currently in development (Focal).
Could you
Based on a suggestion from sarnold in #ubuntu-kernel, I re-ran the tests
of the 4.15, 5.0 and 5.3 kernels in combination with a snap (lxd's snap
specifically) and found no problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Verified to be working on Bionic using the provided test case and
another simpler one (simply stopping haproxy resulted in the error/143
status).
Preparing to unpack .../haproxy_1.8.8-1ubuntu0.8_amd64.deb ...
Unpacking haproxy (1.8.8-1ubuntu0.8) over (1.8.8-1ubuntu0.7) ...
Setting up haproxy
I don't see the patch queued up in Xenial/Bionic for the 4.4.0-170.199
and 4.15.0-72.81 kernels. If I can do anything to help those land (like
test more versions), please let me know.
Thank you!
Simon
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@amitk, would you mind sharing the Apparmor denials you are getting? If
you could include your current profile (and local override) as well
that'd be nice, thanks!
** Changed in: msmtp (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of
** Bug watch added: Debian Bug tracker #933771
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933771
** Also affects: msmtp (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933771
Importance: Unknown
Status: Unknown
--
You received this bug notification because
@mdeslaur, I've deployed your testing PPA more widely (including prod)
and tested various scenarios. I'm happy to report that we found no
problem with your backport. Can't wait for an official package :)
Thanks again!
--
You received this bug notification because you are a member of Ubuntu
@jjohansen, I see that you've included the fix in most of the kernels
currently in -proposed, thanks for that! Although, I'm not seeing those
for 4.4 and 4.15 and I'd like to make sure they don't fall through the
cracks ;)
--
You received this bug notification because you are a member of Ubuntu
fw01/02 have bond0.21 that is setup to have fe80::1 as the VIP used as
the network gateway:
root@fw01:~# ip -6 a show bond0.21
8: bond0.21@bond0: mtu 1500 state UP qlen 1000
inet6 2620:a:b:21::2/64 scope global
valid_lft forever preferred_lft forever
inet6
In our HAProxy deployments, we always add the following drop-in on
Bionic:
[Service]
# XXX: returns 143 when SIGTERM'ed by systemd
SuccessExitStatus=143
It would be great to have the default unit fixed, so thanks!
--
You received this bug notification because you are a member of
*** This bug is a duplicate of bug 1850752 ***
https://bugs.launchpad.net/bugs/1850752
** This bug has been marked a duplicate of bug 1850752
Update amd64-microcode to 20191022 for 17h family
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@mdeslaur, thanks for that! It worked well in my albeit basic tests
using both HTTP/1.1 and HTTP/2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845263
Title:
[wishlist] Add TLSv1.3 support to
I feel really bad now :/
The initial commit that went in doesn't even fix the problem due to a
typo/confusion. The proposed manual workaround was OK but the merge
proposal was not.
"/usr/sbin/rsyslog mr," != "/usr/sbin/rsyslogd mr,"
I'm failing the verification and have proposed a new MP.
Thanks Łukasz and Christian. I find the block-proposed-* tags idea
interesting if that's not too much work on your side.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827253
Title:
[apparmor]
I pulled the various .deb packages from https://launchpad.net
/~canonical-kernel-team/+archive/ubuntu/ppa/+build/17953251/+files/ and
installed them on my Bionic host.
$ uname -a
Linux c2d.mgmt.sdeziel.info 5.3.0-20-generic #21-Ubuntu SMP Wed Oct 23 16:20:37
UTC 2019 x86_64 x86_64 x86_64
I pulled the various .deb packages from https://launchpad.net
/~canonical-kernel-team/+archive/ubuntu/ppa/+build/17945283 and
installed them on my Bionic host.
$ uname -a
Linux c2d.mgmt.sdeziel.info 5.0.0-33-generic #35-Ubuntu SMP Tue Oct 22 01:48:40
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
With
Marking as fix-released as this went in snapd 2.40 according to
https://github.com/snapcore/snapd/commit/1832205560164f725d7400ba0c09b40aa1ba365f
Thanks!
** Changed in: snapd (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of
I'm hitting the same problem when using a Bionic host with a Bionic
container when using the 5.0 HWE kernel.
@paelzer, I'd appreciate if this could be SRU'ed to Bionic, please :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I found your 5.0.0-29 *v2* kernel and gave it a try and I'm happy to
report that you've fixed the problem!
Bionic/5.0 v2:
$ uname -a
Linux c2d.mgmt.sdeziel.info 5.0.0-29-generic #31+v2lp1844186 SMP Wed Oct 2
18:47:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
*result*: works
--
You received
Bionic/5.0:
$ uname -a
Linux c2d.mgmt.sdeziel.info 5.0.0-29-generic #31+lp1844186 SMP Sat Sep 28
18:11:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
*result*: doesn't work
Same behavior as with the official/unpatched 5.0.0-29 (and 5.0.0-30)
kernel, either NNP or Apparmor needs to be disabled
I was surprised to get such an old 5.0 (5.0.0-8 was released in Mar
2019) kernel while all the others were very current. I'm sure you have
you reasons but I'd want to be sure it was not a simple mistake :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Tests results on Xenial:
Xenial/4.4:
# uname -a | sed 's/lxd01\.[^ ]\+/lxd01/'
Linux lxd01 4.4.0-164-generic #192+lp1844186 SMP Thu Sep 26 15:17:42 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
*result*: works
Xenial/4.15:
# uname -a | sed 's/lxd01\.[^ ]\+/lxd01/'
Linux lxd01 4.15.0-64-generic
Tests results on Bionic:
Bionic/4.15:
$ uname -a
Linux c2d.mgmt.sdeziel.info 4.15.0-64-generic #73+lp1844186 SMP Thu Sep 26
15:17:27 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
*result*: works!
Bionic/5.0:
$ uname -a
Linux c2d.mgmt.sdeziel.info 5.0.0-8-generic #9+lp1844186 SMP Thu Sep 26
I tried to reproduce the problem on an unpatched Xenial machine but
couldn't as it seems that /usr/lib/ubuntu-release-upgrader/check-new-
release (from comment #10) doesn't use HTTPS to get to
changelogs.ubuntu.com. If someone has clear steps to reproduce on
Xenial, I'll be happy to try it out.
Public bug reported:
Since LP: #1797386, openssl with TLS 1.3 support is available on Bionic.
This had the nice side effect of enabling TLS 1.3 for various services
(nginx, postfix, dovecot, etc) but not apache2.
TLS 1.3 support is required to use the "modern compatibility"
configuration
Thanks for working on this. I'll be happy to test whatever you come up
with on Xenial/Bionic (4.4, 4.15 and 5.0 kernels) machines.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1844186
Title:
Yes, that's also what I suspected. I haven't been able to catch John
Johansen on IRC to discuss with him about it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1844186
Title:
[regression]
** Description changed:
Description:
Host: Bionic 64 bit with GA kernel (4.15)
Container: Bionic 64 bit
The container runs a binary (/usr/sbin/nsd) locked by an Apparmor
profile. The systemd service is configured with NoNewPrivileges=yes.
# systemctl show nsd | grep ^NoNew
** Description changed:
Description:
Host: Bionic 64 bit with GA kernel (4.15)
Container: Bionic 64 bit
The container runs a binary (/usr/sbin/nsd) locked by an Apparmor
profile. The systemd service is configured with NoNewPrivileges=yes.
- # systemctl show nsd | grep ^NoNew
Public bug reported:
Description:
Host: Bionic 64 bit with GA kernel (4.15)
Container: Bionic 64 bit
The container runs a binary (/usr/sbin/nsd) locked by an Apparmor
profile. The systemd service is configured with NoNewPrivileges=yes.
# systemctl show nsd | grep ^NoNew
NoNewPrivileges=yes
Yeah, this GetDynamicUsers denial is probably unrelated and should/will
be addressed in another bug. Thanks for double checking the alias trick!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841364
I use the alias feature in reverse (doh!). That one did the trick:
# /etc/apparmor.d/tunables/alias
alias / -> /upper/,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841364
Title:
AppArmor
Hi Peter,
If you don't see the value of applying an Apparmor profile to msmtp
please disable it. The package should remember this decision on upgrades
and not re-enable it behind your back.
I do agree that it kinds of defeat the -C option but the Apparmor
profile was designed to accommodate the
As root:
echo 'alias /upper/ -> /,' >> /etc/apparmor.d/tunables/alias
rm -f /etc/apparmor.d/force-complain/usr.sbin.unbound
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.unbound
service unbound restart
Then you should hopefully see no more Apparmor denials.
--
You received this bug
Would you mind testing the alias rule I suggested in comment #3? If it
works, it would in theory fix not only Unbound but every applications
shipping with an Apparmor profile.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Summary changed:
- AppArmor breaks the default Unbound installation
+ AppArmor breaks the default Unbound installation in a live session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841364
That's a valid bug so thanks for reporting! I'll try to do a follow-up
with the relevant folks @Ubuntu regarding possible ways to improve the
experience in the live session. Good luck with your research on DNSSEC!
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Thanks. The live environment being a special one, I'm not sure how to
deal with this at the Apparmor level. Maybe an alias rule ("alias
/upper/ -> /,") would do? Or possibly skip loading the Apparmor profile
when inside a live session?
--
You received this bug notification because you are a
** Changed in: unbound (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841364
Title:
AppArmor breaks the default Unbound installation
To manage
The "/upper" dir in the apparmor denial message makes me suspect that
unbound was installed in the livecd environment. @Tore, is that what you
tried to do? Setting to incomplete while waiting for a confirmation on
the livecd env.
** Changed in: unbound (Ubuntu)
Status: New => Incomplete
Hi Peter,
The failure to read your msmtp's config is probably because it's a
symlink that points to a non-standard location that is not authorized by
default in the Apparmor profile. The Apparmor profile allows the
following locations:
/etc/msmtprcr,
owner @{HOME}/.msmtp* r,
I can confirm that it does work as expected with package
1.14.0-0ubuntu1.3 from bionic-proposed. I tested on my personal site.
Before (1.2 and 1.3 work despite 1.3 not being explicitly enabled):
$ echo q | openssl s_client -connect sdeziel.info:443 -tls1_2 -no_ign_eof
2>/dev/null | grep 'Cipher
On 2019-07-03 10:47 a.m., Christian Ehrhardt wrote:
> I feel bad that this hung around so log, but today I saw it and gave it a
> review.
> This is building in Eoan now.
No worries for the delay, I know where to find you if something more
critical is taking too long to my taste ;) Thank you
@Prakhar, nginx failed to start as something else was already bound to
TCP/80:
Jun 26 13:01:23 prakhar-HP-Notebook nginx[22776]: nginx: [emerg] listen() to
[::]:80, backlog 511 failed (98: Address already in use)
Jun 26 13:01:24 prakhar-HP-Notebook nginx[22776]: nginx: [emerg] listen() to
** Attachment added: "udev-data.list"
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1828275/+attachment/5271914/+files/udev-data.list
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828275
@xnox, thanks it was indeed an error on my part. The key was to have
openssl_conf in the default/unnamed section and then not introduce bogus
values: Ciphers is not recognized and causes the config section to be
ignored.
I believe this bug could be marked as Invalid for all the releases but
I'll
Public bug reported:
[Description]
When setting up a sit tunnel (with Hurricane Electric for example), one
can use a netplan config like (https://netplan.io/examples#connecting-
an-ip-tunnel) this:
network:
version: 2
ethernets:
eth0:
addresses:
- 1.1.1.1/24
-
In my tests, I used NGINX with those TLS related params:
# grep -r ssl_ /etc/nginx/nginx.conf /etc/nginx/conf.d/
/etc/nginx/sites-enabled/
/etc/nginx/nginx.conf: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3,
ref: POODLE
/etc/nginx/nginx.conf: ssl_prefer_server_ciphers on;
Public bug reported:
[Description]
Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
gained access to TLS 1.3 by default. The applications that were not
rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings (protocol,
ciphersuites selection, ciphersuites order) like
I tested the PPA build for Eoan (1.16.0-0ubuntu2p1) and it works as
well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1581864
Title:
nginx.service: Failed to read PID from file /run/nginx.pid:
I tested the PPA build for Bionic (1.14.0-0ubuntu1.3p1) and it works!
systemd never looses track of the main daemon even through 'service
nginx upgrade' cycles.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@ahasenack, yes the only problem is the error message due to the bad
ordering in PID handling. I think the plan is to test TJ's patch via PPA
build to get the green light for upstream submission.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
I tested the PPA build for Bionic (1.14.0-0ubuntu1.3) and it does not
work:
# start nginx in background (as it hangs):
$ sudo systemctl start nginx &
# the parent PID is written to the PIDFile:
$ cat /run/nginx.pid
807
# eventually systemctl start fails and status:
$ systemctl status nginx
●
** Description changed:
+ [Description]
+
Nginx logs an error when started on a machine with a single CPU:
systemctl start nginx
systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
-Loaded: loaded (/lib/systemd/system/nginx.service;
Public bug reported:
Running Chromium's snap result in a lot of Apparmor noise like this:
audit: type=1400 audit(0): apparmor="DENIED" operation="open"
profile="snap.chromium.chromium" name="/run/mount/utab" pid=0 comm="chrome"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit:
301 - 400 of 2435 matches
Mail list logo
