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

fonz wrote:

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....

That's kind of what I was looking for; I did essentially the same thing using the example from this post:

http://dns323.kood.org/forum/t781-Sugge … er%3F.html

The difference between the solution in the above post and using your suggestion (mount --bind from within a properly-named start/ script that runs first) is that the above solution requires only the fun_plug script in the root share.  Since I like to keep things really clean, it'd be nice not to have fun_plug.d/ both in the root share and on the USB key.

On the other hand, your solution keeps things simple and all add-on capability contained within the start/ directory.  So it comes down to this--is it nice to have the ability to avoid the fun_plug.d/ directory in /mnt/HD_a2/ or is it better to keep the fun_plug file very simple and force all add-on triggers to be in the start/ directory?

Now that I think about it though, I'd still need the usb-storage.ko somewhere on /mnt/HD_a2/ which reminds me fonz that you should change your .ko to the updated less-verbose version mentioned in this post:
http://dns323.kood.org/forum/t764-usb-s … ed%3F.html

Oh well, I'd be fine with either method I guess.

fonz wrote:

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 ....

Excellent.  I wasn't sure that this was the case.  Thanks for the code, too, since I didn't know you could capture the text output into a test statement like that.

blbrown wrote:

it'd be nice not to have fun_plug.d/ both in the root share and on the USB key.

You only need the directory as mount point (and as a place to store the kernel modules, if you like). No need to have bin/, sbin/, lib/, start/ et al on disk. Just put the whole fun_plug on the usb key, and create a custom fun_plug script to mount and chain the fun_plug on the usb key. Like

insmod /mnt/HD_a2/fun_plug.d/usb-storage.ko
mount --bind /mnt/usb/fun_plug.d /mnt/HD_a2/fun_plug.d
exec /mnt/usb/fun_plug

The most elegant solution is, of course, recompile the fun_plug for your custom path

On the of features of running fun_plug off a USB stick (that I am looking for) is the
ability to unmount HD_a2 to run fsck.  If you mount your usb/fun_plug.d to
the /mnt/HD_a2/fun_plug.d directory, won't you loose the ability to unmount HD_a2
to run fsck from a telnet session?

mig wrote:

On the of features of running fun_plug off a USB stick (that I am looking for) is the
ability to unmount HD_a2 to run fsck.  If you mount your usb/fun_plug.d to
the /mnt/HD_a2/fun_plug.d directory, won't you loose the ability to unmount HD_a2
to run fsck from a telnet session?

That's probably true (though there might be a trick to work around this). I've always booted my fsck image to do the file system checks.

blbrown wrote:

There's very little chance I'll be recompiling your whole fun_plug package, fonz, so is there any way we can put a bug in your ear to change it for 0.4?  You could compile it to work from /usr/bin (or something more appropriate) and then just have fun_plug do your 'mount --bind' trick so that it doesn't matter where the actual files are...  Please?  With sugar on top?

Ok, I think I figured out an easy solution:  Instead of either fonz or I recompiling the fun_plug package, I can just take 2 minutes and do a string replace in fonz' fun_plug.tar.  I've already done this with fonz' version 0.3, changing 'HD_a2' to 'usb_1', but have yet to try it out.  Fonz, is there any reason this shouldn't work?

Hey Fonz,

Sorry to hear about your laptop. I had a vaguely similar thing on Thursday... I left it on a train!! Luckily some nice lady picked it up and I got it back this lunch time as she was passing through London so I can resume working... and yes - I am an idiot! ;P

Haydn.

UPDATE: I got some work done at last after getting my laptop back, been quite busy for a change as well... anyway:

I've created a small (72kb) install script that can be installed either as /mnt/HD_a2/fun_plug or in /mnt/HD_a2/fun_plug.d/start/whatever which installs ipkg regardless of whether you have any other fun_plug stuff installed. What this script does is:

  - Performs some sanity checks to make sure we have the usual binaries & files needed
  - Gets the mount point of the HDDs ($HD_Path as per /usr/sbin/chk_fun_plug - but nicer)
  - Extract the ipkg binary & libraries from within itself (they're embedded inside the script as a tar.gz file) to $HD_Path/ipkg/[bin|lib]
  - Generates the configuration files based on your $HD_Path and firmware version (e.g: 1.03 - taken from /sys/custom/version/version2.txt)
  - Runs ipkg to install the appropriate firmware package* and the latest base package** from the repository
  - Cleans up (i.e removes itself)

* The firmware package is to allow you to create ipkg's limited to a certain firmware (e.g: 1.03) or set of firmwares (e.g: 1.03+)

** The base package installs lighttpd, php & the latest files for ipkg integration with the standard web config interface. Currently you can list, install and remove packages, start/stop binaries and mark binaries to run at boot or not - I just need to think about configuration options for packages (e.g: port number to run a daemon as), do some security issue checks and then put all the files in an ipkg.

I also need to create a script on the repo so people can submit their own ipkgs, but I'll need to do some documentation first...

Hopefully I should have a release ready next week or the week after if I can find the time!

Haydn.

Hi Fonz,

Firstly let me say that the interface you have provided through fun_plug is excellent -- clean and extensible.  I like it heaps except for hardcoded fun_plug directory.

fonz wrote:

I've also changed the fun_plug script so it should be easy now to move the fun_plug.d wherever you like.

This is great for people like me who are interested in minimal installations -- essentially just shell interface that runs from ramdisk through which one can umount, e2fsck or mke2fs even when running raid0 or raid1.

Jaya

sjmac wrote:

I've just done a little playing around with bzhou's "optware", which has an experimental feed of (1000) binary packages...

I've been having a look also and the amount of packages is great - although some are a little irrelevant (x based apps etc).

sjmac wrote:

Installing the binary ipkg files is very straight forward once ipkg is configured, although if there was a reliable web GUI available, I would use it ;-)

I've very nearly completed my web based gui, all that's left is to update the "action icons" (install, remove, start app, stop app, launch at boot etc) through ajax - currently they don't refresh unless you reload the page. I'm struggling to find the time to get around to this atm which is frustrating as there's so little work left to do... although TBH I will want to rewrite the php stuff when I've finished anyway to tidy it up. After that I will need to write some documentation etc as well... and I also want to make an uploadable testing ipkg feed for people creating new packages.

sjmac wrote:

I guess fun_plug needs to install DNS323 hardware specific stuff (for example optional USB memory key kernel modules, fan control scripts, ...)

Do you think this would be best? Personally I think having separate hardware packages would be better - for example I may not want the fan control scripts but I may want usb key support - having a very minimal install just including the ipkg binaries (and the web based tool) which can then expand to meet my needs exactly by installing whatever packages I want would be my preferred method.

sjmac wrote:

I understand that installing apps below /opt is important to fit in with optware, is that a problem?

I haven't tried too many of the optware packages yet, but I don't think there will be too many that are hard coded to run in /opt.

sjmac wrote:

I have to admit that I'm pretty excited about optware

I'm pretty excited about the use of a package manager through the standard web gui myself - it seems to make things so much easier for non linux peeps and also doesn't require installing telnet (which is insecure) to install things. I have a few reservations regarding how the packages bzhou has created will work with my web gui though, for example I have split the packages up on the configuration page in to services, commands, libs and all so that it's easier to view - however I had to use the "Section" descriptor of ipkg to allow this - something that would require rebuilding the packages to implement (not recompiling!), and I'm not sure how bzhou would feel about me rebuilding packages and putting them on a different feed - I don't want to step on anyone elses toes!

I've uploaded a video here (avi/divx) for you to have a look at to see where I'm up to, you'll see me click reload a couple of times - the effect of which will be done automatically through ajax rather than needing a reload, also it was taken using a 1mb connection shared between about 20 people so the installation of mediatomb in the vid takes a while and I haven't clipped it, although editing the conf file is nice & quick... also you can ignore the error in the title, that's been fixed with the new install script. I'm hoping to have this finished before the end of the week but the way things are going I can't promise...

Haydn.

HaydnH wrote:

I've uploaded a video here (avi/divx)

Wow - that does look nice. Do you think you could get get yourself employed by D-Link for a few months to persuade them to sell the DNS323 as a platform and fully integrate your work in the firmware ;-)

sjmac wrote:

Wow - that does look nice. Do you think you could get get yourself employed by D-Link for a few months to persuade them to sell the DNS323 as a platform and fully integrate your work in the firmware ;-)

Thanks... and I doubt it ;P

BTW - it's pretty easy to install as well there's a 75k (ish) file to upload as /mnt/HD_a2/fun_plug (if you don't have a fun_plug already or /mnt/HD_a2/fun_plug.d/start/whatever if you're using Fonz's fun_plug - it figures out where it should be installed using the same method as the dns-323's standard files) which installs the ipkg binaries, downloads the latest web gui ipk and does some configuration (e.g: adding a few lines to the fun_plug script, copying and editing the standard config pages to add links to the ipkg page etc).

sjmac wrote:

Any chance of anonymous cvs or svn access to ffp 0.5?

Yes, but unfortunately not yet.

sjmac wrote:

BTW, do you see any advantage in using optware to provide the 3rd party apps instead of compiling/distributing them yourself?

I don't know much about optware, but there are a few notable differences:

- At the moment, optware is based on the dlink toolchain while I'm using more recent tools for 0.5 (e.g. gcc4, latest uclibc).

- All current optware ipks are cross-compiled while I'm using native tools for 0.5. Native compilation is slow, but more reliable and also allows to run test suites (more easily).

- ffp 0.5 has its own uclibc, don't know about optware here. Having my own uclibc allows for a few interesting experiments. It's already possible to chroot (like with debian), and with only a few extras, it will be possible to boot and run very recent kernels (with the features you want), all without overwriting the flash memory (and almost no risk).

- ffp is made to fit my needs, optware is more of a general purpose framework. I started all this out of personal interest, and I'm still enjoying it a lot.

In the end, ipkg is just some package tool, and I don't see any problem running ffp and optware in parallel. You'll have two prefixes /ffp and /opt, but that's about it.

jules wrote:

maybe exploiting LD_LIBRARY_PATH

If I remember correcly, a lot of the debian chroot trouble with my 0.3/0.4 version came from setting LD_LIBRARY_PATH. Also, if you don't want to change /bin/sh (another symlink ) you dont know what to put as #! into your scripts... Having a fixed prefix and creating a symlink or bind-mount makes things easier.