DSM-G600, DNS-3xx and NSA-220 Hack Forum

HaydnH wrote:

- Where applications should be installed? The demo below installs everything
    under /mnt/HD_a2/ipkg/[bin|etc|lib] etc, would you prefer everything under
    /mnt/HD_a2/[bin|etc|lib] etc? Somewhere else?

That's a matter of taste. My very first funplug created an 'opt' directory and bind-mounted it to /opt. The wiki funplugs used /mnt/HD_a2/lnx_bin. In the end, I went for fun_plug.d, since it's the directory accompanying the fun_plug script. I'm sure you've noticed, the layout below fun_plug.d is pretty standard.

I advise against using /mnt/HD_a2/{bin,lib,..}. Some use the disk's root directory for 'real' Linux installations. The fun_plug is an add-on that can live in a separate directory tree.

HaydnH wrote:

- Do you have any concerns using ipkg as a package manager?
- Do you have any other ideas/thoughts/concerns regarding this route?

No. If more people start producing add-ons, a package manager might come in handy.

HaydnH wrote:

- Who do I speak to to get a feed setup on http://dns323.kood.org? Or has anyone
   else got a temporary place for a feed? The feed can run from any website,
   however there is a python script to create the index file, it could be rewritten to
   shell though.

Afaik, KRH is the owner of dns323.info.

This sounds really cool. I've used RPM but mostly apt-get for this. Would this only work for linux converted systems or can it be applied to fun_plug boxes? I was wondering about available memory and thought it would be great if we could somehow use the USB key to supplement RAM like they do on other OS's and for USB router on DD-WRT.

If the boxes didn't cost so much I'd pick up a second for testing but as it is I'm not willing to risk my 800gb of media until we're well done a beta path.

Watching with great intrest, please post any results.

Although I've grown weak in Linux over the last 10 years supporting Widows I currently do a lot of installers for XP and Vista. I've never done one for Linux but if it's got a windows based tool or one for a livecd/dvd like Knoppix I can review and attempt to help out.

Otherwise I can test beta's we know wont brick things or kill data. (Sorry but I have no were to stick the 850GB I save on the DNS-323 and I already have about 5 TB of storage at the momant, almost all of it full.)

The rest of your comments are either agreeable to me or make no difference one way or the other provided we continue to do it the same way. The HPMediavault group pretty much did the same thing last year.

Thanks for the good ideas and the knowledge to help make it happen.

Having a very quick look this weekend, the dns-323 uses the goAhead webserver which has support for asp (grrr) and not much else. It is possible to add pages to the configuration pages of the dns-323 although as they're stored in rom (and I don't want to edit the rom at all for obvious reasons!) they need to be copied to the dns-323's HDDs and then mounted back in to place - it works well although there'll be some issues that I'll need to think about regarding future fw upgrades - easy enough to work around safely though.

So - what I want to do is most likely possible without running a second webserver, now I just need to give myself a crash course in asp! Most of the example code I've found (even as simple as Hello World) does't seem to run - although I've got a hello world working now I think the server may have limited functionality so running a second server might still be the only option, unless I can find some documentation for asp support in GoAhead webs which seems thoroughly lacking!

BTW - The conditions of using the GoAhead webserver are that you have a logo on the front page of the site, I haven't noticed any on the dns-323 config pages so either d-link has an agreement with goahead, the condition doesn't apply to these kind of devices or d-link is being naughty!

I'll post back soon when I've figured out goahead/asp... which may be more trial and error than figuring out!

Haydn.

"its not asp its just files whit the asp extension."

The dns-323 runs the goAhead webserver:

/ # telnet localhost 80
HTTP GET foo
HTTP/1.1 400 Page not found
Server: GoAhead-Webs <---
Date: Mon Jan 28 15:01:19 2008
Pragma: no-cache
-- snip --
/ #

The goAhead web server (webs binary) states in it's documentation that it supports asp - however looking at it it appears to be an amazingly crippled form of asp! You can only use @language=javascript (although even trying to set it to javascript fails) and most of the objects are not implemented - i.e: <% Response.write("Hello World!") %> fails but <% write("Hello World") %> works and there's no server object, so no executing command lines through this asp implementation... grrrr!


"to make funcktions to the goahead server you need some source files that dlink not have given us. "

The source code for the goAhead web server is available from their website. To make functions you use their weird cgi/goForms api which looking at the [tiny] amount of documentation available I REALLY can't be bothered to learn it at the minute! It seems a bit strange but as I understand goAhead webs - you use their api and it registers the goForms/cgi function in the webserver binary itself... try running strings on the webserver binary (`strings /web/webs`) and you'll see a ton of functions (and other related junk, html etc) in their which are called through the url's /goForm/foobaa which isn't a real path it just says call the foobaa function from the binary.

I'm almost sure that adding functions to the rom web configuration is possible, however trying to figure out the implementation of goAhead may be a different matter! I'm erring towards creating a lighttpd/php implemntation for now and porting it to goBackwards sometime in the future.

Haydn.

Well I opted to go for an additional web server (lighttpd with php) and have linked it in to the dns-323 default configuration pages successfully, and created a page that can install/remove ipkg packages - hopefully I should have a working demo by the end of the week...

Fonz: I was thinking about to do with the fun_plug script - as some people may want to use this "fun_plug", others will want to use the existing fun_plug and there may be more people wanting to use the fun_plug script for other things in the future. How about changing the default fun_plug script to ONLY look for files in a directory and run any executable files there... that way anyone wanting to use more than 1 "fun_plug" can do so - does that make sense? Comments?

fonz wrote:

Please help me, I'm having trouble understanding what you're really after.

Definitions for clarity:

  - fun_plug script = the /mnt/_HD_a2/fun_plug script or equivelant.
  - fonz fun_plug = your fun_plug package
  - dns-323 extension = Any package that adds functionality to the dns-323 that requires the use of the fun_plug script. (e.g fonz fun_plug)

Sorry, I'll try to be clearer: As standard the DNS-323 has only 1 fun_plug script that is run at boot time. Including fonz fun_plug, the ipkg solution I'm working on and any other fun_plug scripts in the forums there are >1 uses for the fun_plug script. If someone wants to use 2 or more dns-323 extensions using the fun_plug script,  with the current situation, we are relying on the users installing telnet/ssh and either editing the fun_plug script by hand or running a script the dns-323 extension author has made. Let's take some theoretical examples:

  - A user is currently running fonz fun_plug and wishes to install an additional dns-323 extension. The only methods to install the second dns-323 extension either require telnet/ssh access or ftp'ing & hand editing the script and a minimal understanding of the Linux cli

  - A user has more than 1 dns-323 extension installed and wishes to remove one of them. At present this requires hand editing of the fun_plug. Taking fonz fun_plug as an example, we could script it and say remove the first 52 lines from the fun_plug script - but how do we know the code for fonz fun_plug is the first thing in the fun_plug script?


As a solution I was suggesting creating a standard master fun_plug script which never needs to be changed but gives us the possibility to have as many sub fun_plug scripts as we like. i.e: If we copied the "execute all in path for loop" from your  fun_plug script and used that as the master fun_plug script, then to install/remove any amount of dns-323 extensions in fun_plug terms would be as simple as adding/removing a file to/from that path. This is currently possible if a user is using fonz fun_plug - but what happens if a user does not wish to use fonz_funplug?

Of course a dns-323 extension author could create a script to append lines to the standard fun_plug script in "## start/end ##" tags - but this would require telnet/ssh access to run that script rather than just uploading the file via ftp or similar.

Haydn.

fonz wrote:

There should be no need to ever modify this script.
See above, no need to edit the fun_plug, just remove the files.

That's the point I'm making. As it stands there is a need to modify the script if a user wants to use more than 1 package that requires the use of the fun_plug script concurrently while still having the option of running them independently. Consider the benefits of the following changes to a box running your fun_plug - it may get what I'm saying clearer:

# cd /mnt/HD_a2
# mkdir fpscripts
# mv fun_plug ./fpscripts/
# vi fun_plug
# cat funplug   # from your script with a few changes
FPSPWD="/mnt/HD_a2/fpscripts"
LOGFILE="somelogfile"
if [ -d "$FPSPWD" ]; then
    for fun_plug_script in $FPSPWD; do
        if [ -x "${fun_plug_script}" ]; then
            echo "* Running ${fun_plug_script} start ..." >>${LOGFILE}
            ${fun_plug_script} start 1>>${LOGFILE} 2>&1
        else
            echo "* ${fun_plug_script} not executable..." >>${LOGFILE}
        fi
    done
else
    echo "* ${FPSPWD} Directory not found"
fi
#

Now to install your funplug the user would upload it to /mnt/HD_a2/fpscripts and if anyone else needs to use the fun_plug script they can also upload their files to that path and /mnt/HD_a2/fun_plug never need change.

I hope what I'm trying to say is clear enough.

Haydn.

So, instead of putting new scripts into the start directory, you prefer to put new scripts into .../fpscripts? How is that better?

HaydnH wrote:

those who have never touched Linux and would prefer to have an easy web based installer and have no need for telnet (and therefore busybox),

There're quite a few of those on this forum. And with a little help, they had great success installing my funplug. Some asked for additional packages, sure, but nobody complained about not having a graphical installer.

HaydnH wrote:

those who want both a graphical installer and the cli for more control and those, like me, who would be happy with just a cli.

Really, if someone wants to install two or more fun_plug scripts at the same time, he should know how to do this himself. From my POV, this is a non-issue.

There's a need for more packages, yes. But there's no need to create some meta-multi-fun_plug-framework thingy.

Webmin does just that and saves me finding my old notebook of switches and command line tools every time I want to edit a file with vi or update access control.

It does tend to make you command line lazy but for the amount of time I spend on Linux these days a good GUI is a better, faster, solution. Unfortunately the only person who got it to work on a DNS-323 never came back with the install instructions.

HaydnH wrote:

* I imagine there is a mix of people using the dns-323, those who have never touched Linux and would prefer to have an easy web based installer and have no need for telnet (and therefore busybox), those who want both a graphical installer and the cli for more control and those, like me, who would be happy with just a cli.

blbrown wrote:

- ability to dynamically change fun_plug.d/ (or whatever it's called) directory, depending on a USB device being installed--I'd like the ability to run add-ons completely off a USB key if it's present, but run off HD_a2 if it's not present

It's necessary to hardcode some paths. Still, you need to the run the fun_plug from hard disk first, since that's where the firmware looks. If that script detects a usb stick, you can simply
mount --bind /path/to/usb/stick/fun_plug.d /mnt/HD_a2/fun_plug.d and it'll run off the stick....

blbrown wrote:

- setup rules for the add-ons' starting order (whether this is the start/ directory or something similar); there will often be times when one add-on depends on another one, or even depend on whether another one was successful or not

Ordering is trivial, just number the scripts (10-telnet.sh, 20-ssh.sh, 30-nfs.sh, ...) Dependencies are doable, too: if [ "$(10-telnet.sh status)" != "running" ]; then 10-telnet.sh start ....