Create a simple web administration interface

[GoogleCodeExporter]

Enable simple web administration interface to enter config values.
This might be password protected or could be accessible only on first startup 
(until eyefi card number is not entered into config)

Original issue reported on code.google.com by vilius.s...@gmail.com on 23 May 2012 at 7:09

[GoogleCodeExporter]

I'm in a progress of adding an eye.fi web-interface clone in a QPKG version, if 
you don't mind ;)

Original comment by duke...@gmail.com on 20 Jun 2012 at 4:03

[GoogleCodeExporter]

The idea was to handle POST requests of administration interface on the same 
EyeFi server. This functionality should be available on both Qnap and non Qnap 
environments.

Anyways, your contribution is appreciated.

Original comment by vilius.s...@gmail.com on 20 Jun 2012 at 8:20

[GoogleCodeExporter]

Great idea, because restarting/editing the config form PHP is a real problem 
without a root proveleges.

Original comment by duke...@gmail.com on 20 Jun 2012 at 10:38

[GoogleCodeExporter]

Just a note: Images (if needed) should be embeded to the same html page using 
base64.

Like <img
src="data:image/gif;base64,R0lGODlhUAAPAKIAAAsLav///88PD9WqsYmApmZmZtZfYmdakyH5B
AQUAP8ALAAAAABQAA8AAAPb
WLrc/jDKSVe4OOvNu/9gqARDSRBHegyGMahqO4R0bQcjIQ8E4BMCQc930JluyGRmdAAcdiigMLVr
ApTYWy5FKM1IQe+Mp+L4rphz+qIOBAUYeCY4p2tGrJZeH9y79mZsawFoaIRxF3JyiYxuHiMGb5KT
kpFvZj4ZbYeCiXaOiKBwnxh4fnt9e3ktgZyHhrChinONs3cFAShFF2JhvCZlG5uchYNun5eedRxM
AF15XEFRXgZWWdciuM8GCmdSQ84lLQfY5R14wDB5Lyon4ubwS7jx9NcV9/j5+g4JADs=
" alt="British Blog Directory" width="80" height="15" />

Original comment by vilius.s...@gmail.com on 20 Jun 2012 at 10:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Solved a save configuration issue. The only problem for now is to restart 
python script . I suppose this can be done by implementing a configuration 
re-read in python script. Also linked all files in their original locations, 
except of .conf (/etc/config/eyeserver.conf). setcfg removes comments from 
.conf files, so I decided to  clear all coments from it.

Original comment by duke...@gmail.com on 20 Jun 2012 at 2:11

Attachments:

• EyeFiServer_0.3.qpkg

[GoogleCodeExporter]

Source

Original comment by duke...@gmail.com on 20 Jun 2012 at 2:12

Attachments:

• EyeFiServer.tgz

[GoogleCodeExporter]

/usr/local/bin/* won't persist after QNAP reload, rolling back the main script 
call to QPKG path.

Original comment by duke...@gmail.com on 20 Jun 2012 at 2:24

[GoogleCodeExporter]

Version 0.4, added daemon restart from WEB GUI using sudo. As for scripts 
changes:
- added "reload" option to shell and python scripts (python script still making 
a daemon restart with this option, see below)
- added SIGUSR1 handler to python scripts. Unfortunately daemon stops after 
handler executed, this should not be like that!
- added "Daemon started." stderr message at the end of demonize. This is passed 
to WEB interface on restart, along with possible error messages.

The idea is to make daemon reload a configuration on SIGUSR1. 

Original comment by duke...@gmail.com on 21 Jun 2012 at 9:36

Attachments:

• EyeFiServer.tgz

[GoogleCodeExporter]

dukesrg, would you like commit access so you can commit this directly to the 
tree?

Original comment by davidgrant on 24 Jun 2012 at 5:41

[GoogleCodeExporter]

I've gone ahead and give you commit access. Welcome!

Original comment by davidgrant on 24 Jun 2012 at 5:42

[GoogleCodeExporter]

Great, thanks! Should I make a separate braanch for QPKG version?

Original comment by duke...@gmail.com on 24 Jun 2012 at 6:59

[GoogleCodeExporter]

I'd prefer just one code-line. Is there any reason that it can't be on
trunk? Sorry I know nothing about qpkg, qnap, etc...

Dave

Original comment by davidgrant on 24 Jun 2012 at 7:26

[GoogleCodeExporter]

QPKG source for qbuild needs several additional files and special directory 
structure:
├── build
├── config
│   └── eyefiserver.conf
├── icons
│   ├── EyeFiServer_80.gif
│   ├── EyeFiServer.gif
│   └── EyeFiServer_gray.gif
├── package_routines
├── qpkg.cfg
└── shared
    ├── eyefiserver.py
    ├── eyefiserver.sh
    └── web
        ├── api.php
        ├── css
        │   ├── center.css
        │   ├── desktop.css
        │   └── share.css
        ├── favicon.ico
        ├── images
        │   ├── dimicon-networks.jpg
        │   ├── eyefi-logo-v2.png
        │   ├── gear-v2.png
        │   └── settings_white-tab-v2.png
        ├── index.php
        └── js
            ├── functions.js
            └── jquery.min.js
The code itself may be universal. For now the only changes for QPKG version 
comparing with the trunk files (exept locations) are:
- changed ':' to '=' in .conf file to be compatible with config files 
manipulation binaries in QNAP (getcfg and setcfg, python works fine with that 
format too. Though setcfg/getcfg is a proprietary QNAP binaries, I suppose, so 
WEB-interface will fully work on QNAP only)
- changed .sh script to suport start/stop/restart/reload operations with 
additional QNAP-related service snabled status checking. Can be rewritten to be 
universal for any linux version, not only QNAP.
- In .py only changed .pid file to lowercase and added an initial support for 
signal handling and "reload" option, which is OS independent.

So we can update the current trunk, but all we will have is working .sh script 
and partly unusable "reload" option support. The better option is to have a 
separate brunch for QPKG with .py/.sh/.conf files and web-resources linked with 
the main trunk, but I'm not sure this is possible.

Original comment by duke...@gmail.com on 24 Jun 2012 at 8:02

[GoogleCodeExporter]

Hmm, yeah it looks like maybe it is better to have a separate branch and we
can pull patches to the .py file between branches.

OR...

just split things up a bit better. There could be one common .py file, then
a QNAP-specific main() .py file and a plain main() .py file that uses the
common file.

Then, the other thing we need is a script to create 2 tarballs: 1) plain
.tar.gz or .egg or .deb or whatever we want, 2) QNAP .tar.gz.

I assume you guys can do the QNAP-side of things. I can take care of the
non-QNAP side of things.

Dave

Original comment by davidgrant on 24 Jun 2012 at 8:37

[GoogleCodeExporter]

Well .py file is not QNAP-specific at all, so there is no need to have a 
separate  main() versions. The only reason I implemented a signal handler is to 
start developing a config reload without daemon restart, which is usable at all 
platforms. I'll try to rewrite a web GUI without using setcfg/getcfg and 
without PHP to reduce segmentation.

Original comment by duke...@gmail.com on 25 Jun 2012 at 4:12

[GoogleCodeExporter]

Andrej, I'd suggest not to commit a main py file to the qpkg directory. 
Instead - make a pre-build script, which copies the py script to qpkg/shared 
directory. QDK supports that.
The configuration script should not be separated also, as it is dependent on 
the same py script.
Startup script (if really necessary) might be separated, as they strongly 
depend on the environment.

Original comment by vilius.s...@gmail.com on 25 Jun 2012 at 11:52

[GoogleCodeExporter]

Startup, python and config files are the same now. We just need to decide now 
how to arrange common and device-specific files and make a build scripts. BTW I 
can't find pre-build options for qbuild, only pre-install.

Original comment by duke...@gmail.com on 25 Jun 2012 at 11:57

[GoogleCodeExporter]

The quote from QDK documentation:
The next script is the pre-build script, specified with the --pre-build option 
or by using the QDK_PRE_BUILD variable. This script could be useful to make any 
package specific changes before each build, for example architecture specific 
handling like building a binary for the current architecture or include a 
pre-packaged archive for the current architecture.

Original comment by vilius.s...@gmail.com on 25 Jun 2012 at 7:26

[GoogleCodeExporter]

Got it.
The last problem - for linux version, where config is in /etc and not a 
symlink, it is almost impossible to change it via the web application. Granting 
sudo for sed for the http user is not a good idea at all, so the only way is to 
place .conf file into accessible directory and create a symlink.

Original comment by duke...@gmail.com on 25 Jun 2012 at 8:31

[GoogleCodeExporter]

I guess the conf file could have write permission for group and the group
could be http or www-data or whatever the webserver is running as.

Does the symlink even work to elevate the permission of the file in /etc ?

Original comment by davidgrant on 25 Jun 2012 at 8:40

[GoogleCodeExporter]

Unfortunately sed won't work correctly in inplace mode without write 
permissions on a parent directory. symlink is dereferenced in script, otherwise 
in inplace it will be rewritten by a new file, which is again impossible 
without write access on directory level. Granting write access to www user on 
/etc/is not an option, you know.

Original comment by duke...@gmail.com on 26 Jun 2012 at 3:47

[GoogleCodeExporter]

Original comment by duke...@gmail.com on 26 Jun 2012 at 7:48

• Changed state: Started

[GoogleCodeExporter]

Original comment by duke...@gmail.com on 26 Jun 2012 at 7:49

• Changed state: Fixed

[GoogleCodeExporter]

I'll open a new issue for config write problem

Original comment by duke...@gmail.com on 26 Jun 2012 at 7:51