Call for Testing: Inadyn Dynamic DNS Client

[lucyllewy]

sudo snap install inadyn

You probably want to create a configuration file. The location of the file is helpfully returned by running

inadyn.configpath

You need to edit this as root, because it’s saved into $SNAP_DATA for use by the daemon which is controlled by systemctl under the service name snap.inadyn.daemon.service.

It should be easy to edit the config with something like:

sudo $EDITOR $(inadyn.configpath)

The configuration file format is described at inadyn’s github: https://github.com/troglobit/inadyn

[anagno]

Hello,

I tried to install the snap to a nextcloud box. The snap installs correctly, but I get errors will trying to configure the inadyn. Mainly that I do not have permissions to create the files and if I manage to create them, the inadyn can not access them. Could you write some instructions on how to configure the snap?

Sorry for the basic questions, but I am quite new to the snap technology.

Cheers,
Vasilis

[lucyllewy]

Are the instructions above not working for you?

Some helpful questions which might illustrate your problem better for me to comprehend:

• What commands did you run?
• Were there any error messages?
  if so please paste them along with the commands which prompted those errors…
• Does the log in journalctl report anything about the inadyn service?

  sudo journalctl snap.inadyn.daemon.service
  

• Have you tried restarting the inadyn service using systemctl?

  sudo systemctl restart snap.inadyn.daemon.service
  

Note that unless you install inadyn unconfined by using devmode then it will currently fail with:

Not allowed to change owner of /var/snap/inadyn/<number>, aborting.

Where <number> is the current revision of the snap, such as 8. This is due to apparmor and seccomp preventing chown. There is a thread about that.

Chown to current user

Multiple snaps are failing to run when packaged with strict confinement due to fchown being a blocked syscall. Can we please get a fix for this syscall to allow “chown to myself” into snapd? This will, for example allow things like glib file creation to work out-of-the-box where gimp-2.9.6 as an example currently cannot start because it gets killed when calling fchown on a file it creates to ensure it’s owned by the user who created it. We should also convert the denial to a “permission denied” …

[anagno]

@lucyllewy

Are the instructions above not working for you?

Some helpful questions which might illustrate your problem better for me to comprehend:

What commands did you run? Were there any error messages?

if so please paste them along with the commands which prompted those errors…

Here is the output from some snap commands that are probably useful for debugging reasons.

...@...:~$ sudo snap install inadyn
snap "inadyn" is already installed, see "snap refresh --help"

...@...:~$ snap services
Snap       Service         Startup  Current
inadyn     daemon          enabled  inactive
nextcloud  apache          enabled  active
nextcloud  mdns-publisher  enabled  active
nextcloud  mysql           enabled  active
nextcloud  nextcloud-cron  enabled  active
nextcloud  php-fpm         enabled  active
nextcloud  redis-server    enabled  active
nextcloud  renew-certs     enabled  active
snapweb    snapweb         enabled  active

...@...:~$ snap version
snap    2.29.3
snapd   2.29.3
series  16
kernel  4.4.0-1030-raspi2

...@...:~$ snap list
Name           Version       Rev   Developer     Notes
core           16-2.29.3     3443  canonical     core
inadyn         0.1           10    snapcrafters  -
nextcloud      11.0.5snap2   3685  nextcloud     -
pi2-kernel     4.4.0-1030-3  22    canonical     kernel
pinano         2.8.7         9     vbota         -
snapweb        0.26-10       305   canonical     -
wdl-nextcloud  16.04-0.5-6   9     canonical     gadget

When I try to edit the configurations and save them using:

sudo pinano $(inadyn.configpath)

I get

I used pinano as snap for the nano-editor, because it was the only one available for the raspberry pi architecture. Do not pay attention on the configurations. I know that they are probably wrong, but one problem at time For the moment I can not save the configurations and have the snap read them.

@lucyllewy

Does the log in journalctl report anything about the inadyn service?sudo journalctl snap.inadyn.daemon.service

And the output from the commands you provided:

...@...:~$ sudo journalctl snap.inadyn.daemon.service
Failed to add match 'snap.inadyn.daemon.service': Invalid argument

@lucyllewy

Have you tried restarting the inadyn service using systemctl?sudo systemctl restart snap.inadyn.daemon.service

...@...:~$ sudo systemctl restart snap.inadyn.daemon.service
(This was succefull and did not produce any output, so I am pasting the output from the syslog)

...@...:~$ sudo tail -f /var/log/syslog 
Nov 26 20:59:03 nextcloud systemd[1]: Started Service for snap application inadyn.daemon.
Nov 26 20:59:03 nextcloud kernel: [18981.549762] audit: type=1400 audit(1511729943.282:89): apparmor="DENIED" operation="chown" profile="snap.inadyn.daemon" name="/var/snap/inadyn/10/" pid=22015 comm="inadyn" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Nov 26 20:59:03 nextcloud inadyn[22015]: Not allowed to change owner of /var/snap/inadyn/10, aborting.
Nov 26 20:59:03 nextcloud systemd[1]: snap.inadyn.daemon.service: Main process exited, code=exited, status=73/n/a
Nov 26 20:59:03 nextcloud systemd[1]: snap.inadyn.daemon.service: Unit entered failed state.
Nov 26 20:59:03 nextcloud systemd[1]: snap.inadyn.daemon.service: Failed with result 'exit-code'.
Nov 26 20:59:03 nextcloud systemd[1]: snap.inadyn.daemon.service: Service hold-off time over, scheduling restart.
Nov 26 20:59:03 nextcloud systemd[1]: Stopped Service for snap application inadyn.daemon.
Nov 26 20:59:03 nextcloud systemd[1]: snap.inadyn.daemon.service: Start request repeated too quickly.
Nov 26 20:59:03 nextcloud systemd[1]: Failed to start Service for snap application inadyn.daemon.

The link you provided probably answers the question why this is happing. Probably the pinano does not have the permissions to write the necessary configurations files (Am I correct???). Is there a way of bypassing this restriction?

@lucyllewy

Note that unless you install inadyn unconfined by using devmode then it will currently fail with:

Not allowed to change owner of /var/snap/inadyn/<number>, aborting.

Where <number> is the current revision of the snap, such as 8. This is due to apparmor and seccomp preventing chown. There is a thread about that.

Multiple snaps are failing to run when packaged with strict confinement due to fchown being a blocked syscall. Can we please get a fix for this syscall to allow “chown to myself” into snapd? This will, for example allow things like glib file creation to work out-of-the-box where gimp-2.9.6 as an example currently cannot start because it gets killed when calling fchown on a file it creates to ensure it’s owned by the user who created it. We should also convert the denial to a “permission denied” …

Is there a way of resolving that??? In the syslog, I saw the message that your are mentioning. I did not understand what I have to do from the links Although not new to linux, I am really new to snaps and unfortunately did not have the chance to play with them yet

[lucyllewy]

@anagno

When I try to edit the configurations and save them using:

sudo pinano $(inadyn.configpath)

I would guess that the pinano snap does not have permission from apparmor and seccomp snap confinement to access the /var/snap/inadyn directory which is why you can’t write the file using that. To work around it, you could write the file on your normal PC and scp /path/to/inadyn.conf yourpiusername@pi.ip.add.ress:~ and then login to the pi via ssh and sudo mv inadyn.conf /var/snap/inadyn/10/inadyn.conf.

@anagno

Is there a way of resolving that??? In the syslog, I saw the message that your are mentioning.

The currently easiest way to get working is to run:

sudo snap refresh --devmode --revision=10 inadyn

which will turn-off the confinement. Note that this will mean that the snap will be able to access your entire system, so you might prefer not to follow this advice if you’re keen to maintain the security of your system.

[anagno]

@lucyllewy

The currently easiest way to get working is to run:

sudo snap refresh --devmode --revision=10 inadyn

which will turn-off the confinement. Note that this will mean that the snap will be able to access your entire system, so you might prefer not to follow this advice if you’re keen to maintain the security of your system.

This resolves all the problems for both inadyn and pinano Since this breaks the purpose of having snaps, could you suggest me some material to read and learn in the process about snaps? What would be generally the correct procedure for configuring a snap???

Thank you in advance and sorry for this basic questions

[jdstrand]

As mentioned in: Chown to current user

"
As mentioned elsewhere, this will be fixed as part of the work for Multiple users and groups in snaps. This work is on the roadmap but not prioritized. To help out, I’m working on this in the background so while it is progressing, it is progressing slowly. Note that chown to root:root is currently allowed.

In the meantime applications can either be patched to not perform the chown or use the snapcraft preload part: https://github.com/sergiusens/snapcraft-preload.
"

I suggest that inadyn use the snapcraft-preload part since it will turn “chowns to myself” to no-ops.

[lucyllewy]

@jdstrand

use the snapcraft-preload part since it will turn “chowns to myself” to no-ops

Yes, you’re quite right. I had it on my todo list but haven’t got around to it yet. I’m going to go do that now