awsome Thomas!. You got it!. Having the doc in any snap path can be rendered. So, that answers the point of chroot working ok, but now there is another problem: How can I access documents in other snaps? Can content interface solve this? (I'll try)
On 09/02/17 14:04, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón > <roberto.escan...@canonical.com> wrote: >> >> Hey Thomas, >> >> You can find the snap at [1] >> Atttached are traces for: >> >> Devmode: >> - service.txt are the logs of the service >> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor >> denials (warnings in this case). I cannot see more than ptrace ones. >> >> Classic: >> - service.classic.txt >> here i don't see any denial >> >> The only error shown is that the document has not been found. But the >> url is the same in classic or devmode, so that's not the reason of the >> problem. >> > > Okay, so I don't see the chroot setup failing at all (according to > your logs). Where is the document located in the local file system? > If your snap works with classic confinement, it might live outside of > the snap itself. > >> >> [1] https://github.com/rmescandon/loolwsd-snap >> >> BR. >> >> On 09/02/17 10:32, Thomas Voß wrote: >>> Hey Roberto, >>> >>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón >>> <roberto.escan...@canonical.com> wrote: >>>> Hey engineers, >>>> >>>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>>> online but that's not being easy at all. FYI: this is a kind of Google >>>> Drive stuff so that when you request in your browser certain document, >>>> it is rendered and can be edit by many at the same time, etc.. >>>> >>>> Though I've been able to build from sources a snap package, that is only >>>> working in classic confinement but not in devmode or strict. >>>> >>>> The reason is because the way it works: >>>> - There is a server listening for documents requests >>>> - for every new document requested an instance of a document manager is >>>> started in a chrooted environment >>>> - If requested n documents there will be n different chroot jails based >>>> in same certain template >>>> - document manager has certain linux capabilities to create the needed >>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>>> - the way of packaging the snap, currently, is by setting those caps and >>>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>>> >>> >>> Could you please elaborate what is not working and how it fails? >>> System logs, apparmor denials >>> and seccomp messages would be needed here for further debugging. >>> >>> What is going wrong in the devmode case? >>> >>> Thanks, >>> >>> Thomas >>> >>>> I thought about a solution of having server in a snap and document >>>> manager in another, but still there would be needed calling chroot for >>>> every new document... ideas? >>>> >>>> BR. >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft@lists.snapcraft.io >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >> >> -- >> Snapcraft mailing list >> Snapcraft@lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
