WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Autostart script for/on mounted volumes?  (Read 3156 times)

Offline tnussb

  • Newbie
  • *
  • Posts: 10
Autostart script for/on mounted volumes?
« on: May 13, 2012, 05:03:56 AM »
When using larger software packages like one or more JDK installations or Ruby on Rails with a larger gems archive it's quite useful to store them on separate volumes and plug them into the filesystem which some links for direct usage.

The default persistence way of tinycore isn't really an option here, because it would waste tons of RAM and would take too long to decompress during start.

It would be nice if there would be some plug-and-play mechanism to do all the initialization stuff "auto-magically" when a volume is recognized by the system and mounted. IMHO the easiest and most generic way would be an autostart script (with a special name) stored on each volume.

Any ideas where and how to patch this into the system? Since there is already a scanning for the TCE directory on availables volumes it shouldn't be hard.


Offline gutmensch

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 605
  • I can make it disappear, have no fear!
    • remembrance blog
Re: Autostart script for/on mounted volumes?
« Reply #1 on: May 13, 2012, 07:31:05 AM »
There is still the opt= bootcode, so if you're installing miscellaneous external stuff (like e.g. binaries from third-party vendors), you can just put it all on your hard drive into the folder /opt with opt=sda1 as boot code. For other personal use like netbeans, RoR gems, etc. I would suggest using e.g. the home=sda1 boot code to have a persistent home directory on your hard drive. Remove all opt and home entries from /opt/.filetool.lst and you're ready to go. Those two possibilities were always sufficient for everything I was doing, so personally I don't see a real need in patching the system somewhere else.
If I seem unduly clear to you, you must have misunderstood what I said. (Alan Greenspan)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Autostart script for/on mounted volumes?
« Reply #2 on: May 13, 2012, 08:12:42 AM »
Yay for unsecure-as-hell conventions from Windows!

So quite certainly not as default. But if you do need it, you'd either hook to udev or rebuildfstab.
The only barriers that can stop you are the ones you create yourself.

Offline tnussb

  • Newbie
  • *
  • Posts: 10
Re: Autostart script for/on mounted volumes?
« Reply #3 on: May 15, 2012, 05:59:59 PM »
Why this stupid windows bashing? My background is in no way MS windows, I haven't asked for this to become the default way and speaking of "unsecure-as-hell": mounting a volume as home is at least equally unsecure.

For my environment (a kind of cloud) it's quite useful, because larger software distributions are stored on their own volumes, which are shared between multiple machines (mounted read only).

With the autostart scripts on the volumes each single machine doesn't need to know anything about the software packages, where to hook them up in the directory tree and which special preparations are required to initialize them.

BTW: How is security handled with the tinycore repository and all the available packages out there? As far as I have seen some of them are quite old ...

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
Re: Autostart script for/on mounted volumes?
« Reply #4 on: May 15, 2012, 06:45:03 PM »
Well, it is not handled by running whatever some wag put in an autoexec file on a CD.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Autostart script for/on mounted volumes?
« Reply #5 on: May 16, 2012, 05:21:09 AM »
Yes, the extensions are user-contributed, and that means they can be some versions behind. We aren't an Enterprise distro, with support charges and guaranteed security updates for every package.

Purely mounting the exact volume the user told to mount can only be a risk if the fs driver is buggy; and why would the user do that to themselves (specifically craft the file system to crash the driver). Autostart script on the other hand will come from any source.

edit: I understood you meant someone modified the home. That means they had physical access, and could have harmed your system in numerous other ways too.

Maybe someone finds an usb stick in the parking lot.
« Last Edit: May 16, 2012, 05:23:41 AM by curaga »
The only barriers that can stop you are the ones you create yourself.