Bug#921538: Fails to start since upgrade to 1.9.0-1
On 2019-02-09 8:28 p.m., Robert Edmonds wrote: > Probably it's better to use the --with-chroot-dir= argument to configure > rather than directly patching the source to change the default. Indeed and that's what's being proposed in the merge request. Regards, Simon
Bug#921538: Fails to start since upgrade to 1.9.0-1
On 2019-02-08 7:26 a.m., Kepi wrote: > Chroot workaround is working for me too. Good. > Anyway in the long term would it be better to have chroot setup > automatically again? I found out that it was working before, at least > some work was done in #579622 for auto support. The auto-chroot setup was broken with the (welcomed) move to systemd notify. I have a working PoC to restore the functionality that I'll submit soon as another merge request. Regards, Simon signature.asc Description: OpenPGP digital signature
Bug#921538: Fails to start since upgrade to 1.9.0-1
Here is a merge request [*] to disable chroot'ing again like it has been since version 1.0.0-3 Regards, Simon *: https://salsa.debian.org/dns-team/unbound/merge_requests/3 signature.asc Description: OpenPGP digital signature
Bug#921538: Fails to start since upgrade to 1.9.0-1
Hi Ryan, On 2019-02-06 11:12 a.m., Ryan Kavanagh wrote: > Since the upgrade to 1.9.0-1, unbound fails to start. Purging the > package and reinstalling does not fix the issue. The errors seem to be > due to being unable to read various configuration files. > > Feb 06 11:01:12 zeta unbound[28647]: [28647:0] error: unable to open > /var/lib/unbound/root.key for reading: No such file or directory > Feb 06 11:01:12 zeta package-helper[28648]: [1549468872] > unbound-checkconf[28651:0] error: Could not open > /etc/unbound//etc/unbound/unbound.conf: No such file or director It seems like chroot'ing to /etc/unbound is attempted. To workaround you can try this: cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "" EOF service unbound restart Regards, Simon signature.asc Description: OpenPGP digital signature
Bug#919326: msmtp: account default not found: no configuration file available
On 2019-01-14 6:03 p.m., Sergio Mendoza wrote:
> Yes. I have now checked and I have .msmtprc as a symlink. If it is not
> a symlink then I have no problems and everything runs smooth.
Great, thanks Sergio.
> In any case
> this is the output you asked for:
>
> root@quetzalli:~# dmesg | grep apparmor | tail -n 20
> [1064151.025521] audit: type=1400 audit(1547506707.004:157):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/Private/.msmtprc" pid=14560 comm="msmtp"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
This should eventually work even when ~/.msmtprc will be a symlink to
~/Private/.msmtprc. I hope the fix will land in the next package update [*].
> [1064177.994021] audit: type=1400 audit(1547506733.971:158):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/mail/msmtp/log.txt" pid=14580 comm="msmtp"
> requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
> [1064281.325901] audit: type=1400 audit(1547506837.302:159):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/mail/msmtp/log.txt" pid=14656 comm="msmtp"
> requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
This shows that msmtp was denied logging to ~/mail/msmtp/log.txt.
Unfortunately, this isn't a common location to for logs so it likely
won't be supported by the default base Apparmor profile. You have few
options to make it work though:
1) you can have it log to more usual locations like one of those:
~/.msmtp.log
~/.cache/msmtp/*.log
2) add this local override rule to /etc/apparmor.d/local/usr.bin.msmtp:
owner @{HOME}/mail/msmtp/log.txt wk,
3) disable the Apparmor profile
1 would be preferable but for 2 and 3, please refer to the README.Debian
file for detailed instructions.
Regards,
Simon
*: https://salsa.debian.org/kolter/msmtp/merge_requests/3
Bug#919326: msmtp: account default not found: no configuration file available
Hi Sergio, On 2019-01-14 5:40 p.m., Sergio Mendoza wrote: > A few days ago, msmtp fails to work. It all seems to be related to the > inability to read ~/.msmtprc file. In other words it seems that > ~/.msmtprc needs to have mode 644. This is not at all desired since > sensible (private) information can be included in that file. The package > msmtp should run with no trouble when the user configuration file > ~/.msmtprc has mode 600. Indeed, it should work with ~/.msmtprc with mode 0600. Is it working when you have it set to 0644? > I am sending you some useful output so that you can check the relevance of > the > situation (please note that I tried playing with stable, testing and sid > versions of msmtp and I get the same output -this lead me to think whether > the problem is with msmtp or with some other related package): > > >> > > sergio@quetzalli:~$ echo "Hello World" | msmtp -d ser...@mendozza.org > ignoring system configuration file /etc/msmtprc: No such file or directory > ignoring user configuration file /home/sergio/.msmtprc: Permission denied > falling back to default account > msmtp: account default not found: no configuration file available > > > > As such, the bug leaves the package fully unusable. That's unexpected but could be related to the Apparmor profile changes that went in recently. Is /home/sergio/.msmtprc a symlink by any chance? If yes, could you share the output of "ls -l /home/sergio/.msmtprc"? Could you please also share the output of "dmesg | grep apparmor" Thanks in advance, Simon
Bug#662960: ssmtp doesn't validate server TLS certificates
On 2019-01-09 10:23 a.m., Cédric Dufour - Idiap Research Institute wrote: > PS: ssmtp is extremely handy to forward machine-generated messages in large > deployments, internally, iow. where TLS is not required ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a similar way, is well supported and does the right thing when you want TLS. Regards, Simon
Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start
On 2017-11-23 03:12 PM, Jack Henschel wrote: > $ sudo dmesg -T | grep apparmor > ... > [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:8): > apparmor="STATUS" operation="profile_load" profile="unconfined" > name="thunderbird" pid=498 comm="apparmor_parser" > [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:9): > apparmor="STATUS" operation="profile_load" profile="unconfined" > name="thunderbird//gpg" pid=498 comm="apparmor_parser" > [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:10): > apparmor="STATUS" operation="profile_load" profile="unconfined" > name="thunderbird//lsb_release" pid=498 comm="apparmor_parser" > [Thu Nov 23 21:01:24 2017] audit: type=1400 audit(1511467287.665:11): > apparmor="STATUS" operation="profile_load" profile="unconfined" > name="thunderbird//sanitized_helper" pid=498 comm="apparmor_parser" > > I does not seem like apparmor is blocking anything. Agreed, Apparmor doesn't seem to get in the way. Thanks for checking! Regards, Simon signature.asc Description: OpenPGP digital signature
Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start
On 2017-11-23 12:18 AM, Carsten Schoenert wrote: >> Also, directly running /usr/lib/thunderbird/thunderbird-bin works, too! >> Which is really weird because /usr/lib/thunderbird/thunderbird and >> /usr/lib/thunderbird/thunderbird-bin are the same, but only the latter one >> can connect to the X server. >> $ sha256sum /usr/lib/thunderbird/thunderbird* >> 126efa3f01f0d86c9d97702a90f163013ad1667e1a326fd193d61c72e034584e >> /usr/lib/thunderbird/thunderbird >> 126efa3f01f0d86c9d97702a90f163013ad1667e1a326fd193d61c72e034584e >> /usr/lib/thunderbird/thunderbird-bin >> a3f9e5f5820436e7205a0223ce6a7dee89b30bcf626e6de92f43fee4a2c87b24 >> /usr/lib/thunderbird/thunderbird-wrapper-helper.sh >> $ ls -l /usr/lib/thunderbird/thunderbird* >> -rwxr-xr-x 1 root root 126040 Oct 17 18:20 /usr/lib/thunderbird/thunderbird >> -rwxr-xr-x 1 root root 126040 Oct 17 18:20 >> /usr/lib/thunderbird/thunderbird-bin >> -rw-r--r-- 1 root root 14545 Oct 7 11:35 >> /usr/lib/thunderbird/thunderbird-wrapper-helper.sh >> >> What could be the difference between thunderbird and thunderbird-bin? > > I really don't know the reason why. I can remember in the past both > binaries have a different size and one of them was used for calling > Thunderbird for running on a remote side. That has changed sometimes > between version 20 and 30 I guess. > > Nethermind, I will modify the wrapper script we are using to call > thunderbird-bin with the next upload. Currently, the Apparmor profile only applies to /usr/lib/thunderbird/thunderbird so if you change the wrapper script to call the "-bin" version, it would side step Apparmor. Maybe side stepping Apparmor is what made the "-bin" version work? That's a wild guess (I don't run Debian) but if that's the case, it would be better to fix the Apparmor profile. An easy way to check if Apparmor gets in the way would be to start thunderbird (no "-bin") and then run: dmesg -T | grep 'apparmor="DENIED"' If anything comes up please attach it in here. Regards, Simon signature.asc Description: OpenPGP digital signature
