Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change user group and access rights #126

Merged
merged 2 commits into from
Jan 21, 2018
Merged

Change user group and access rights #126

merged 2 commits into from
Jan 21, 2018

Conversation

cniweb
Copy link
Member

@cniweb cniweb commented Jan 15, 2018

Fixes #123

Signed-off-by: Christian Häussler [email protected] (github: @cniweb)


This change is Reviewable

Fixes #123

Signed-off-by: Christian Häussler <[email protected]> (github: @cniweb)
@dfrap
Copy link

dfrap commented Jan 17, 2018

My testing of these changes does not fix #123 My system still does not log, but perhaps it fixes the issue for others.

N.B. Using chmod removes the ACL permissions that were set with:
...synoacltool -add ${filename} ${DAEMON_ACL}
DAEMON_ACL="user:${DAEMON_USER}:allow:rwxpdDaARWc--:fd--"
If the ACL permissions are not useful, perhaps setting them should be removed from the install script. But I would suggest the synoacltool commands remain to be used in some future revision.

When an ACL is set for a directory, the ls command will indicate and ACL is set by showing a + following the permissions.
ls -e with -l will show syno-acl permission details for any directory. root permission or sudo is needed to see the same details with synoacltool -get I am still puzzled as to why the ACL and Unix access permissions are different between userdata, conf, and addons. I regret that I have not been able to spend the time to debug the cause.


Review status: 0 of 1 files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

Signed-off-by: Christian Häussler <[email protected]> (github: @cniweb)
@cniweb cniweb merged commit a4f2445 into master Jan 21, 2018
@IRTermite
Copy link

Concur with @dfrap
I too am still getting 0 sized Log file and nothing added to config on a fresh SNAPSHOT install.
Manually set the perms too 770 on the paths as well for conf and userdata. Didn't touch addons yet. Still nothing.
This is installing to /var/services/homes/openhab
2.3.0.001-SNAPSHOT
DSM 5.2-5644

@dfrap
Copy link

dfrap commented Apr 10, 2018

@IRTermite I finally got logging working by updating the logging config file. The root cause appears to be the change in Karaf versions at build #1009. See Karaf Upgrade4 for details: https://community.openhab.org/t/karaf-upgrade/33208

It appears that the logging config file is not upgraded on install of new versions so the user needs to upgrade it manually. So my ‘fix’ was to remove /volume1/public/openHAB/userdata/etc/org.ops4j.pax.logging.cfg and replace it with the version from https://openhab.ci.cloudbees.com/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab/target/openhab-2.3.0-SNAPSHOT.zip1

So if your Synology openHAB won’t log, the process seems to be:
Uninstall the openHAB package
Update the Karaf customization file: org.ops4j.pax.logging.cfg
Reinstall your desired level of openHAB - 2.2.0.010 works for me

@cniweb cniweb deleted the cniweb-patch-1 branch April 11, 2018 21:11
@cniweb
Copy link
Member Author

cniweb commented Apr 11, 2018

@kaikreuzer Is it necessary to delete org.ops4j.pax.logging.cfg during an update?

@kaikreuzer
Copy link
Member

@cniweb It should be overwritten by the latest version, yes.
This means that user customisations of the logging will be lost until we have a solution for openhab/openhab-distro#516.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants