SynoCommunity / spksrc

Cross compilation framework to create native packages for the Synology's NAS
https://synocommunity.com
Other
3.02k stars 1.23k forks source link

[syncthing] guidance on compiling for rtd1296 #3019

Closed mwcz closed 6 years ago

mwcz commented 6 years ago

For new Package Requests, see the guidelines

Setup

Package Name: Package Version:

NAS Model: DS418 NAS Architecture: rtd1296 DSM version: DSM 6.1.4-15217 Update 2

Expected behavior

I'd like to use syncthing on my DS418. I added rtd1296 to cross/syncthing/Makefile's list of arm arches, so I can compile it now. The issue I'm hitting now is that syncthing's Makefile has a WIZARDS_DIR but the dir doesn't exist.

I removed the WIZARDS_DIR and the compilation worked, but I'm looking for guidance on whether that's a good idea. This is my first stab at creating a package, and I'm not sure whether or not a wizard is needed for syncthing. I haven't used syncthing before either, I'm just looking for a syncing service for my NAS that isn't a Disk Station thing (it annoys me to to no end that it's locked to the CloudStation directory only).

I have syncthing now running on my DS418 (installed without a wizard), and it seems to be working. Another thing I'm hoping to get guidance on is how to set up permissions so syncthing can actually share files. Right now it doesn't have file permissions for anything in /var/services, where all the good stuff lives.

I'm also hoping to learn about creating these packages. The DS418 currently has barely any packages available, and if I can get some practice creating them, hopefully I can help fix that.

That was a lot, but it tl;dr's down to these questions:

  1. is a wizard needed for syncthing?
  2. what's the ideal file permissions setup to allow syncthing to share out users' files?

Actual behavior

Steps to reproduce

1. launch spksrc docker container 2. add rtd1296 to list of arm arches in cross/syncthing/Makefile 3. run `make arch-rtd1296

Package log

Check Package Center or /usr/local/{package}/var/

Insert the package log here

Other logs

Here's the log complaining about the wizards directory missing.

root@93ed753b360b:/spksrc/spk/syncthing# make arch-rtd1296
===>  Building package for arch rtd1296
make[1]: Entering directory '/spksrc/spk/syncthing'
(cd /spksrc/spk/syncthing/work-rtd1296-6.1/staging && tar cpzf /spksrc/spk/syncthing/work-rtd1296-6.1/package.tgz --owner=root --group=root *)
===>  Creating checksum for syncthing
===>  Preparing DSM Wizards
find: `src/wizard/': No such file or directory
../../mk/spksrc.spk.mk:261: recipe for target 'wizards' failed
make[1]: *** [wizards] Error 1
make[1]: Leaving directory '/spksrc/spk/syncthing'
../../mk/spksrc.spk.mk:419: recipe for target 'arch-rtd1296' failed
make: [arch-rtd1296] Error 2 (ignored)
ymartin59 commented 6 years ago

Looks like package is broken. Try again after removal of WIZARDS_DIR variable in Makefile

cytec commented 6 years ago
  1. the WIZZARDS_DIR variable can be deleted. Seems like the DSM6 branch has an old/broken Makefile for syncthing. i've mentioned that somewhere else a few days ago...

  2. i don't know about DSM 6 but for DSM5 that would be setting the access rights to include the sc-sync group. WRT /var/services syncthing runs as non admin/root user so you won't have access to /var/sercives either open up the rights so it has access or copy the files somewhere else and sync them from there

mwcz commented 6 years ago

Thanks for the help!

@ymartin59 The compilation does work after removing the WIZARDS_DIR variable, the question I was getting at was whether that's a good idea. I just wasn't familiar enough with syncthing to know if it needed a setup wizard or not. Sounds like it's a-okay so I'll proceed without WIZARDS_DIR.

@cytec The issue (at least, I think it's an issue) with copying the files elsewhere is that if the files are outside of /var/services, no other services can see them (ie, DS File, Photo/Audio/Video Station, etc). Alternatively, I can open up the permissions for sure, but that doesn't help others who want to use syncthing. I'd like to get a build of syncthing published for rtd1296 so others can use it, but right now it's not usable without a blanket chmod.

mwcz commented 6 years ago

Ah, maybe this is the best approach... instead of sshing into the NAS and changing file permissions, I used the DSM Control Panel to grant rw permission to the user sc-syncthing and group sc-syncthing for the homes directory (more accurately, /var/services/homes). It's happily syncing now.

I'd like to publish syncthing for rtd1296. Is requiring the above permission changes as a post-install step acceptable for synocommunity packages?

cytec commented 6 years ago

WIZARDS_DIR isn't needed for syncthing to work, i don't know why it even is there...

regarding the permission changes: i don't think that's a good idea at all... we provide the sc-sycnthing group for a reason. So every user can set the access rights for syncthing as he want's to... i'm not seeing any point in forcing users to open their permissions if they don't want to. I'm useing syncthing since the beginning and never ever synced anything above the shared folder level which i guess most users will do...

\cc @ymartin59

mwcz commented 6 years ago

I wouldn't consider changing the permissions, except for the fact that sc-syncthing does not have permission to any of the "standard" (for lack of a better term) file space on the NAS. On my NAS, it has access to /usr/local/syncthing/var/, but all the files are stored in /var/services. If I were to move all my sync'd files to /usr/local/syncthing/var/, none of the other services on the NAS would be able to see them.

Again, I'm very new to Synology NAS's, so I could easily be missing something, but as far as I can tell, the out-of-the-box experience with the syncthing package on the DS418 is that it has no access to the good stuff.

cytec commented 6 years ago

AFAIK syncthing is part of sc-syncthing and users group. So you should generally be able to sync everthing a normal user can access as well as fine tune permissions so syncthing can access the folder but normal users can't. Since /var/services is owned by root and those are mostly system relevant symlinks i don't think that there is a way to provide a solution for this out of the box.

Running such a package as root isn't the best idea imho. So i guess your best bet would be: either add syncthing to the root group which might work, or open up the permissions...

steinerlein commented 6 years ago

Is it to be expected that this arch will be added to the SynoCommunity package resources?

mwcz commented 6 years ago

@cytec I'm still not sure why syncthing wasn't able to sync files until I gave it rw access to /var/services/homes. I'll do some more investigation to find out if that permission change is really as necessary as it seemed to me at first.

@steinerlein I would like to publish it, but there are some permissions problems I experienced and the best solution isn't clear yet. Perhaps I could post my build somewhere for others to try out? (I've never done this before so the level of handholding is really off the charts)

steinerlein commented 6 years ago

@mwcz I understand your position absolutely. I have installed the syncthing binary manually for now, but I wasn't able to do much testing at all. I used this method: https://forum.syncthing.net/t/how-to-install-syncthing-arm-release-on-synology/2285/2

I think a package would be a lot nicer and should be easily possible as the binary for the architecture is there already. I am using this one on my DS218play: https://github.com/syncthing/syncthing/releases/download/v0.14.42-rc.1/syncthing-linux-arm64-v0.14.42-rc.1.tar.gz

mwcz commented 6 years ago

@steinerlein Here's the syncthing package I generated. About the permissions issue, I had given the sc-syncthing group r/w on the homes dir (via DSM, not CLI), in order to get syncthing to work for me. I just tried revoking that permission and it still works, so... maybe this is good to go? Would appreciate testing!

syncthing_rtd1296-6.1_0.14.30-13.spk.zip

sha1 for the spk file (not the zip): b136ffe184b8dee3f6caec84ea038a096f1fa2a4

GitSchorsch commented 6 years ago

@mwcz i'm new here, but i've found this thread when searching for syncthing for my new DS218play. A first test was successful. After setting r/w permissions for the sc-syncthing group the folder was synchronized. Great work!

GitSchorsch commented 6 years ago

@mwcz i've set up some more synchronisation folders between my DS218play and my Raspberry Pi 3 and getting the following error:

shortcut chmod: chmod [path to file to synchronize]: operation not permitted

I've gave sc-syncthing group r/w access to all shared foldes using DSM. Did i forget something?

mwcz commented 6 years ago

@GitSchorsch I saw similar errors several times. I fixed it in the syncthing web UI: go to the shared folder settings and check "Ignore Permissions". This has to be done for every shared folder (if there's a way to set it globally, I'd love to know about it!)

Thanks for testing it too, I'm glad it worked for you! If you don't mind, could you try removing sc-syncthing group's r/w access? I really want to be sure that's necessary before recommending. I was able to remove the r/w permission and syncthing still works.

GitSchorsch commented 6 years ago

@mwcz it seems, that "Ignore Permissions" resolves the problem. I've tested something due to permissions:

  1. add a new folder without setting r/w permissions: Ths results in the follwing error messages:

    2017-12-27 22:25:49: Loading ignores: open /volume1/Test/.stignore: permission denied 2017-12-27 22:25:49: Creating folder marker: stat /volume1/Test/.stfolder: permission denied 2017-12-27 22:25:49: Error on folder "Test" (test): stat /volume1/Test/.stfolder: permission denied Also it was not possible to add ignore patterns.

  2. set r/w permissions before adding the folder to synching Everthing was fine, synchronisation works like a charm. Ignore patterns can be added ("Ignore Permissions" was set).

  3. remove the r/w permission Synchronisation to the remote-server was possible, but changes from the remote-server couldn't be synchronized:

2017-12-27 22:35:22: Error on folder "Test" (test): stat /volume1/Test/.stfolder: permission denied

With r/w permissions and "Ignore Permission" it seems to be stable without any error messages. I've synchronized more than 70GB mp3 files and more than 660GB movies without any problems within my local network.

Thank you for the package, great performance.

mwcz commented 6 years ago

@GitSchorsch That's fantastic, thank you for the thorough testing!

mwcz commented 6 years ago

@cytec After @GitSchorsch's testing I'm more confident in the package working. I'm ready to submit a PR but have three questions still:

  1. Contrib instructions say "Build rule all-supported completed successfully". I've tried this but ran into a bunch of problems related to GOROOT not being set. Once I set it (for me go is installed in /usr/bin), I started seeing errors like build.go:12:2: cannot find package "archive/tar" in any of: followed bya list of dirs.
  2. Next, contrib instructions ask that a Package upgrade completed successfully. I'm not sure how to accomplish this. Install the same spk again and make sure syncthing still works?
  3. Whether or not to include instructions for setting permissions. @GitSchorsch seems to confirm what I originally thought, that giving sc-syncthing permissions to homes is required for syncthing to be able to sync files in a user's home. If instructions should be included, where should they go?

Thanks for your patience and assistance!

cytec commented 6 years ago
  1. you shouldn't need to set GOROOT at all... GOPATH should be more then enough...
  2. Package upgrade completed successfully means: Install the SPK then build it again with a higher version and update the SPK through DSM. This is mostly needed for packages providing a config/var folder that needs to presist.
  3. Well if that's the case i think the best solution would be to add a wizzard file that pops up when installing that tells you if you want that youll have to give permissions accordingly (\cc @ymartin59). I'd go with something like CP does: https://github.com/SynoCommunity/spksrc/tree/master/spk/couchpotatoserver/src/wizard maybe so basically copy the wizard dir over, change step_title and and desc to reflect whats going on and include it in your Makefile like this: https://github.com/SynoCommunity/spksrc/blob/master/spk/couchpotatoserver/Makefile#L26
mwcz commented 6 years ago

Thanks a bunch! I'll try again to see if the GOROOT errors still bite, and I'll try out adding a wizard.

capi1O commented 6 years ago

Thank you very much for this package, it installed correctly but after configuring one folder I cannot access the UI anymore (at :7070).

Also, when uninstalling the package, trying to reinstall it leads to "not available" error message. The /var/log/messages log is synoscgi_SYNO.Core.Package.Installation_1_install[26626]: privilege_api.cpp:346 Failed to set default owner of syncthing [0x2000 bdb_get.c:40]

I tried to remove groups sc-syncthing and syncthing (sudo synogroup --del), also a directory left at /usr/syno/etc/packages/syncthing but the issue remained. Only after reboot I could reinstall the package again.

DiskStation DS418, DSM 6.1.5-15254

Safihre commented 6 years ago

Please use the packages in #3138. This package uses an outdated concept that we have since abandoned.