tuxpoldo

Members
 View Profile  See their activity

  • Posts

    730

  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Everything posted by tuxpoldo

  1. tuxpoldo
    Hi Jarulf, the configuration file is fine, since it is autogenerated. In any case you should post it completely (also with comments, since they may contain additional configuration information). Please do the following and post the output: sudo /usr/lib/btsync/btsync-daemon --nodaemon --config /etc/btsync/debconf-default.confp.S.: why are you using the server version on a desktop system?
  2. tuxpoldo
    I would also like to insist on this.
  3. tuxpoldo
    Very simple syntax error: there is a comma missing after the storage_path line The next time, please include the contents of your config file in the message, it would be much more simpler as adding screen shots.
  4. tuxpoldo
    Hi, this is correct. In this first stage, I tried to address the most urgent requirement of some users that contacted my - and that was to create a dedicated user/group for btsync and permit to run the default instance under that credentials. But I'm planning for the next release to enhance the selection to select from all users of the system.
  5. tuxpoldo
    Released new btsync server package 1.2.1-1 with a few bugfixes and some great new features (see changelog for details). Both Debian and Ubuntu builds are online on debian.yeasoft.net - The Ubuntu builds on Launchpad will be probably available in 2-4 hours . If you are Ubuntu User and prefer to switch to the debian.yeasoft.com repository, you should delete the file tuxpoldo-btsync-precise.list in your /etc/apt/sources.list.d directory and follow the instructions in the initial posting. And here the change log: btsync (1.2.1-1) unstable; urgency=low * Allow the default instance to run also as dedicated user instead of root (Closes #47) * Added support for API key in default instance (Closes #48) * Duplicate instance check a startup not always working with certain name patterns (Closes #49) * Improved syslog messages -- Leo Moll <leo.moll@yeasoft.com> Tue, 10 Dec 2013 18:18:52 +0100
  6. tuxpoldo
    Sorry GreatMarko, this is wrong and not only now but since 1994 when I started writing system services for Windows NT. Look at the original WIN32 documentation of the function CreateFile : http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx HANDLE WINAPI CreateFile( _In_ LPCTSTR lpFileName, _In_ DWORD dwDesiredAccess, _In_ DWORD dwShareMode, _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes, _In_ DWORD dwCreationDisposition, _In_ DWORD dwFlagsAndAttributes, _In_opt_ HANDLE hTemplateFile);The magick happens if you merge in dwFlagsAndAttributes the bits FILE_FLAG_POSIX_SEMANTICS. The documentation says: "Access will occur according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support that naming. Use care when using this option, because files created with this flag may not be accessible by applications that are written for MS-DOS or 16-bit Windows." Apart of that there are several good ways to handle such problems.
  7. tuxpoldo
    It would be difficult, because all scripts reference the indicator. But perhaps it would be interesting to find out, what components would be needed make the indicator running also in squeeze. Have you tested if the wheezy package of python-appindicator can be installed also on squeeze or if there is an alternative way to get it working? If yes, we could prepare a customized version for squeeze. I would really appreciate this. This could improve substantially the documentation.
  8. tuxpoldo
    It seems that the package does not exist for Debian squeeze: http://packages.debian.org/wheezy/python-appindicator Unless the library is contained in another package, probable it is not possible to use the btsyncindicator on squeeze. Since I have no desktop test system running on squeeze, I have no idea how to solve the problem...
  9. tuxpoldo
    I suppose you are using the btsync-user package. In this case, you should read carefully the initial posting. There is a detailed documentation on how you can run the instance with a user specific configuration file (And in this file you can specify a specific port). The /etc/btsync-user/btsync-user.conf file is only a template for the specific automatic configuration file created on each login. It is not a good idea to specify a fixed port there, since in case of multiple users of the system, there would be a port conflict.
  10. tuxpoldo
    I added Ukrainian to the project. You can now start your work at the PO Editor btsync-deb project. Thank you very much for your help!
  11. tuxpoldo
    I fully agree with this! Both marxjohnson and me are currently waiting for answers regarding use and conditions of the API and have suspended any development that could base on the API since it is totally unclear if external open source developments using the API are wanted... The Terms and Conditions together with the API key are currently an obstacle for many new developments....
  12. tuxpoldo
    Alex, one question: are you using the latest version? There already was such a bug in the past and it was fixed by adding a double instance check in the indicator itself (See btsyncindicator Issue #25). Before modifying my startup script, I would be glad to know, if you are really using the latest version.
  13. tuxpoldo
    I suppose you are using the btsync-user package including Mark Johnson's btsyncindicator applet. Is this correct? If yes, you should first look, if the process is running. You can do this by entering the following command: pgrep -u $(id -u) -f btsyncindicator.py If you get back a number, the process is running. In this case it is definitively an issue of the btsyncindicator component. You should check the open issues and the related discussion on GitHub (https://github.com/marxjohnson/btsyncindicator/issues?state=open). If not, we should investigate further...
  14. tuxpoldo
    Version 1.2.82 still does not solve the problem....
  15. tuxpoldo
    The problem on x86 GEODE CPUs is still not solved with 1.2.82. Any Idea when the bugfix will be released? I know that there is a solution upcoming...
  16. tuxpoldo
    Thank you for the tip! It seems that the system behaves differently on different desktops. I will integrate your change into the next release. Referenced as Issue #50 (See https://github.com/tuxpoldo/btsync-deb/issues/50)
  17. tuxpoldo
    Your question was "How do I change the default permissions of new files to 766?" - not "How do I change the user under which credentials the daemon runs?" But I will give you good news: you will also find the answer to that question in the initial posting. Using DAEMON_UID=<username> was the right way to do it. One tip: you can find out more in the system log and also when starting manually the daemon with service btsync restart, if you uncomment the last line (the one with DAEMON_INIT_DEBUG) in the file /etc/default/btsync
  18. tuxpoldo
    You are really funny ;-) The link you posted is an (outdated) summary of the topic in this forum I mentioned in my previous post. Additionally it contains also links to the original forum topic.
  19. tuxpoldo
    Hi Mike, You can configure both the port to use for the web interface (you can also disable it) and the ports used by the btsync replication mechanism. If you are installing on Debian, take a look at the Debian and Ubuntu Server Packages. Please read carefully the initial posting in order to understand your possibilities and options.
  20. tuxpoldo
    Yes. It is correct and totally irrelevant for your case. On any normal unix system, the runlevel S is something very particular. On your NAS it's not. It is the standard runlevel. It is so, because the guys that have designed the OS of your NAS have decided to do so. Your NAS is an embedded system. An embedded system is not so complex as a real computer with many users working on it. That may be the reason why the guys that developed the NAS decided to design everything to run in runlevel S.
  21. tuxpoldo
    OK. Let's do it manually... update-rc.d -f btsync removeupdate-rc.d btsync start 40 S . stop 40 0 6 . Tell me please what's happening
  22. tuxpoldo
    Impressing! Thank you for the report. I will fix it in the next release. In the meantime you may replace the lines with: if [ $(ls -l ${CONFIG_DIR}/${BASENAME}.${CONFIG_EXT} ${CONFIG_DIR}/${BASENAME}.*.${CONFIG_EXT} 2> /dev/null | wc -l) -gt 1 ]; then log_error_msg "Duplicate instance name $BASENAME found. Interrupting sequence." exit 1 fiSee https://github.com/tuxpoldo/btsync-deb/issues/49
  23. tuxpoldo
    If your openwrt box is based on a geode processor (pc-engines/alix), it's more likely that the issue reported here (http://forum.bittorrent.com/topic/24686-error-btsync-does-not-run-on-x86-compatible-geode-processors-illegal-instruction) is the cause of your problem. At least I can tell you, that the developers are working on it.
  24. tuxpoldo
    In any case the file shows us a fundamental difference between the btsync service and all other services installed on the system. Nearby every service will be started at runlevel S (that means Single user mode - see https://wiki.debian.org/RunLevel). Only btsync (and deluged - whatever this may be) are configured for running at runlevels 2,3,4,5. Differently from a standard Debian installation, your NAS seems always to boot into the Single user mode runlevel, and this explains why btsync does not start automatically. The automatic installation routine seems to take the default runlevels from the comment in the init script: #!/bin/sh### BEGIN INIT INFO# Provides: btsync# Required-Start: $network $remote_fs $syslog# Required-Stop: $network $remote_fs $syslog# Should-Start: network-manager# Should-Stop: network-manager# Default-Start: 2 3 4 5# Default-Stop: 0 1 6# Short-Description: btsync Service# Description: This script will start btsync service instances as specified# in /etc/default/btsync and /etc/btsync/*.conf### END INIT INFO# Author: Leo Moll <leo.moll@yeasoft.com>Basically it should be possible also to deploy an init script without these comments. In this case, the system should decide to use some default values in order to register the service. Can you please make the following test and tell me about the results? First of all, unregister the service: update-rc.d -f btsync removeAnd now check your /etc/runlevel.conf file in order to see, if btsync has really been removed. Now remove the comment block from ### BEGIN INIT INFO to ### END INIT INFO from the /etc/init.d/btsync init script. Then reregister the service: update-rc.d btsync defaultsAnd now check if something in /etc/runlevel.conf has changed. My idea is that this should work, if your NAS knows, that the Single user runlevel is default for service installation... If this does not work, repeat the entire procedure, but instead of deleting the block, edit it with the following values and test the procedure again: ### BEGIN INIT INFO# Provides: btsync# Required-Start: $network $remote_fs $syslog# Required-Stop: $network $remote_fs $syslog# Default-Start: S# Default-Stop: 0 6# Short-Description: btsync Service# Description: This script will start btsync service instances as specified# in /etc/default/btsync and /etc/btsync/*.conf### END INIT INFO
  25. tuxpoldo
    And perhaps it is a good idea to start btsync as the last of the normal services. Change the sort key to 41 and move it before 99: 41 0,6 S /etc/init.d/btsync