[nas-2000] Re: restart

Having some of your Tinky fetures on my box would be nice. So a solution
which is more or less independed from the specific device would be fine.

I like the layout having all twinky stuff in one folder, but I think for the
"DUAL HDD NAS" I use (what a stupid name) it's not enought. The way they
store the config settings is totaly different from the NAS 1000/2000.

Regards,

Tom

Am 16.05.2007 10:42 Uhr schrieb "flipstar@xxxxxxx" unter <flipstar@xxxxxxx>:

> Hi everybody,
> 
> first of all I have to say that I'm tired of debugging
> the ftp! guess we'll find the bug one day but when???
> The next thing is that tinky has no clean design (if there
> is any at all).
>> From my point of view it would be over all
> better if we would make a clean cut and think
> about the design tinky should have.
> 
> Next thing is that I deleted
> quite a but from the original firmware which
> didn't made sense like usb and raid support but now with
> the new kernel it makes perfect sense ...
> 
> So here are some ideas as always please
> comment and make suggestions.
> 
> #
> #
> # tinky
> # 
> # new tinky layout
> # directory structur
> #
> /system/overlay/tinky
> apps
> data
> libs
> modules
> rc.d  
> bin
> 
> 
> /system/overlay/tinky
> The tinky dir is for configuration
> files etc.
> - savedata.conf
> - tinky.conf (?)
> 
> 
> Question:
> Do we want a tinky.conf (guess yes)
> we could give the user the possiblilty to
> define special variables like:
> 
> ...
> USE_ENCYPTED_SWAP=yes
> USE_HD_CRYPT=YES
> USE_HD_CRYPT_KEY="/<usb-stick>/tinky.key"
> ...
> just to give an example
> 
> Note:
> We should really stop using seperate start and
> stop scripts and do it the common way with
> a start and a stop funktion in one file
> 
> 01_example.sh
> 
> ...
> start() {
> 
> }
> stop()  {
> 
> }
> ...
> 
> 
> /system/overlay/bin
> for all the installed bins
> 
> 
> Question:
> does a seperate bin dir for tinky scripts make sense
> to get a cleaner layout???
> 
> 
> Some bit's I don't want to forget:
>  
> the 2. busybox (Version 1.5) that is now part of the
> Ramdisk /bin/busybox-1.5.0 should be an ordinary ipk-file
> so we/the user can easily upgrade.
> As the content of the $PATH variable it processed (from left to rigth)
> it should be possible to "overright" commands that are already on the system
> with new "feature richer" like this:
> 
> old vi:
> ls -l /bin/vi -> busybox (old)
> 
> new vi:
> ls -l /system/oberlay/apps/busybox/vi -> busybox-1.5.0 (new)
> 
> PATH="/system/overlay/apps/busybox:/bin/"
>  
> 
> the busybox.conf (bbconf?) should be stored in /system/overlay/tinky
> but busybox complains about rights of this file. does it complain
> about a symlink as well???
> No hussle with save and restoer
> 
> inetd.conf should be a symlink to /system/overlay/tinky/..
> No hussle with save and restoer
> 
> We need to find a clear way how a update if the FW is handelt:
> 
> Today the /etc/rc script only checks if the dir /system/overlay exists and
> if not copy over the stuff from the Application-"Partition"
> At leased we need a handler like:
> 
> if the file update-fw exists
> 
> if [ -e /system/overlay/update-fw ]; then
> copy over the stuff from
> the Application-"Partition"
> 
> 
> any ideas???
> 
> 
> Ok this was a rather ugly braindumb but the only thing
> I wanted to start was a discussion.
> Im sure you guys have some ideas and suggestions
> 
> bye
> 
> --
> flip

Other related posts: