post install
Forum: myDSL Extensions (deprecated)
Topic: post install
started by: mikshaw
Posted by mikshaw on Sep. 04 2005,14:33
minimally tested FINAL EDIT: This first test was a failure, since i had some misconceptions of the DSL init process. Don't listen to anything I say in this first post.
The topic of a post-install script in myDSL extensions comes up once in a while....we were talking about it last night on irc, and I thought i'd give it a go. This first idea does not require a remaster, but instead uses a myDSL extension to add the post-install capability. It is simply an extension containing an edited version of /etc/init.d/mydsl-install, and named something like "0-POSTINSTALL.tar.gz" so it will be the first extension loaded in an auto-load situation (and will not bother running mkwriteable if you don't have a need for it).
The mockup post-install code, added to /etc/init.d/mydsl-install AFTER the "case $APP" and BEFORE "umount":
| Code Sample |
| mydslPOSTINST="/tmp/mydsl.postInstall/postinst.sh" if [ -x "$mydslPOSTINST" ]; then sh $mydslPOSTINST && chmod -x $mydslPOSTINST fi |
I had originally hoped to use the APP variable in the script, but it wouldn't have worked if the package was ever renamed. The "chmod" isn't necessary, but as an afterthought it might be useful for something.
It requires adding a script named /tmp/mydsl.postInstall/postinst.sh to any package using post install behavior. This script needs to be executable.
It DOES NOT work with uci extensions. I don't think i want to bother incorporating post-install into mounted apps.
EDIT: After some minor tests it seems to work fine, both at boottime and with user-initiated install.
Test archive here:
link to crappy script removed. Better version available farther along in this thread
Archive contains 3 myDSL packages: The post-install (edited mydsl-install script), one *.tar.gz test and one *.dsl test.
Don't test on anything but a non-persistent liveCD or frugal, just to be safe.
EDIT2: I just remembered that mydsl-install is run as root, which would mean that the post-install script is currently also run as root. Just something to keep in mind.
EDIT3: My bad...it doesn't work at boot time, since dsl-config doesn't run mydsl-load...it extracts the contents of the archives with tar directly.
Posted by yyyc514 on Sep. 04 2005,18:47
Of course this approach won't work for apps loaded at boot because as we discussed last night further steps need to be taken.mydsl-install is not called from dsl-config... it instead installs all the packages itself... so you actually need to inject a special script into runlevel 2 or 5 (you could put it in S, but I don't think the list of things to run is dynamically reloaded, when dsl-config is running it's probably already scanned rcS for things to run and too late to add anything).
And since multiple packages can be installed at boot (before we have the ability to run post-install scripts) they really do need to be named according to the package... package names should be ALMOST static so I don't see this as a big deal... You could also name them sequentially, which might make sense for ordering of dependencies... 0.install, 1.install, 2.install, etc...
And since it isn't happening immediately I'm still not a big fan of using /tmp... but maybe that's the only writable place at this point, not sure... so you'd have...
/tmp/mydsl.postInstall/gtk2
/tmp/mydsl.postInstall/gimp
/tmp/mydsl.postInstall/xfce
The names really don't even matter... You could even dump:
/temp/mydsl.postInstall/gimp-step1
/temp/mydsl.postInstall/gimp-step2
Of course I have no idea why you wouldn't just have one script, but not locking the names approach allows this additional flexibility.
At startup the final script loops over any of these files running them... there should also really be some mechanism to catch failures and leave the scripts for manual intervention, but that might be stage two...
If I have time this week I'll see about implimenting the full mechanism and updating the 4 test packages I maintain to use the new system...
Thoughts?
Posted by yyyc514 on Sep. 04 2005,18:59
Ok, take my # idea back... it didn't make much sense... it'd require a lot more logic to take a certain file and order it for later execution...My next question is... in light of the fact that I think failures should be handled gracefully is this the script or controllers job?
There are two approachs I see... the "master" script runs instlals, checks for success, removes install scripts or prints error and leaves it (for manual intervention)...
Or the master script is more dumb and just runs thigns in order and the install scripts have more logic... I like this approach... an install would either print an error and then exit... or print success (or do nothing) and rm $0 (remove itself)... seems a very clean approach to me...
Not much effort on the master and really not much additional effort on the install script maintainers... we should all be checking for errors in some rudimentary form at least... right? :-)
Posted by yyyc514 on Sep. 04 2005,19:09
My proposal (I just wrote this off the top of my head):Added to /etc/init.d/mydsl-install (after case/esac and before umount)
| Code Sample |
. /etc/init.d/mydsl-postinstall |
/etc/init.d/mydsl-postinstall
| Code Sample |
for file in `ls /tmp/mydsl.postInstall/*`; do $file done |
/etc/rc2.d/S25post_install and
/etc/rc5.d/S25post_install
| Code Sample |
-> (link to) /etc/init.d/mydsl-postinstall |
Of course it might be a little more complex than that.. but that's the jist of it... the only issue with this system is packages overlapping names during boot up... ie you couldn't install TWO gimps... packages could not overlapp their /tmp/mydsl.postInstall files... if there is gimp1 and gimp2 (as in having both versions installed) those would be the respective names of their install files...
This addresses all of my previous thoughts i think and it still trivially simple...
Posted by yyyc514 on Sep. 04 2005,19:13
Though truth be told I don't like camelCase directories...maybe /tmp/mydsl_postinstall/ instead or add another underscore? of course i don't really care too much :-)
Posted by yyyc514 on Sep. 04 2005,19:37
NOT TESTED< post_install.dsl >
Testers welcome... I'm going to change my packages to work with this and see what happens... If you're a package maintainer and want to give it a run for the money, feel free...
Please report any issues or further thoughts or considerations. :-)
no, it doesn't do anything by itself... it's just the infrastructure to support packages having post-installs
Posted by mikshaw on Sep. 04 2005,19:59
I think you're making this much more complicated than it needs to be. I tested the edited /etc/init.d/mydsl-install and it works fine, even for auto-loaded apps. The key for that part is to name the extension as above, 0-POSTINSTALL.tar.gz (all caps) so that it will load first before any other extension, even those beginning with "00000001AAAAA" or something like that, which is very unlikely. Not that someone couldn't name it "0-Asomething", but why would they? But maybe it should just be named 0-0.tar.gz just to make sure it will be found before anything else.The current myDSL system is not set up to install a bunch of files at once. Each file found at boot goes through the process individually, so it might be difficult to set up a directory of post-install scripts to run all at once without making more complex changes to the system. If it works fine by adding a few lines to mydsl-install, i'm completely satisfied with that. The above runs a script after an application is installed (if the script is included in the package), and that's all i care about. I like the way myDSL works now, so i have no intention of involving myself in a rewrite
As far as failures go, i guess it would depend on where it fails. I would guess that if it is the post-install script failing, it would be up to the packager to make sure it works properly.
Directory names i don't care about, especially if they are just tmp directories. As long as a filename doesn't include a space or some other stupid character, i really don't care what the name is.
EDIT: by making your post install *.dsl, you are putting unnecessary limits on the enduser....me, for example. I hardly ever run mkwriteable, and like to keep all apps in home and opt.
Posted by yyyc514 on Sep. 04 2005,20:58
| Quote (mikshaw @ Sep. 04 2005,15:59) |
| I think you're making this much more complicated than it needs to be. |
My solution was all of like 6 lines and 1 new file (and 2 symlinks)... more complicated than your solution, yes... much more complciated than it needs to be, no. :-)
| Quote (mikshaw @ Sep. 04 2005,15:59) |
| I tested the edited /etc/init.d/mydsl-install and it works fine, even for auto-loaded apps. The key for that part is to name the extension as above, 0-POSTINSTALL.tar.gz (all caps) so that it will load first before any other extension, even those beginning with "00000001AAAAA" or something like that, which is very unlikely. Not that someone couldn't name it "0-Asomething", but why would they? But maybe it should just be named 0-0.tar.gz just to make sure it will be found before anything else. |
I have NO idea how it could... mydsl-install is _not_ called during bootup as far as I can determine from source... all the installations are performed by dsl-config (and it doesn't call mydsl-install either)... so I don't know how your post-install code could even be run...
| Quote (mikshaw @ Sep. 04 2005,15:59) |
The current myDSL system is not set up to install a bunch of files at once. Each file found at boot goes through the process individually, so it might be difficult to set up a directory of post-install scripts to run all at once without making more complex changes to the system. |
It's quite possible, and should work fine in most cases. :-) I still don't see how your solution could really work reading the code... And the loop really only happens at boot... the rest of the time it is one at a time... again, I don't see how what you wrote could work and don't see another solution except what I have proposed.
| Quote (mikshaw @ Sep. 04 2005,15:59) |
I like the way myDSL works now, so i have no intention of involving myself in a rewrite |
Again, overstatement. What I offer is far from a "rewrite" of myDSL. :-)
| Quote (mikshaw @ Sep. 04 2005,15:59) |
As far as failures go, i guess it would depend on where it fails. I would guess that if it is the post-install script failing, it would be up to the packager to make sure it works properly. |
Of course, but sometimes a script can still fail... unless it's a pristine CD one can't guarantee what environment it's going into... did you like the idea of making them unexecutable when finished rather than deleting? I caught that in your initial idea.
| Quote |
| EDIT: by making your post install *.dsl, you are putting unnecessary limits on the enduser....me, for example. I hardly ever run mkwriteable, and like to keep all apps in home and opt. |
Hmmm... It's main purpose is for dealing with .dsl packages that are subsequentially installed... so mkwritable is going to get called soon enough anyways, but I'll give this factor some thought...
Posted by undertow on Sep. 05 2005,00:25
i filled out my application and took the beta-tester job. yyyc514's four dsls are semi-functional together, although skippy locks up X and keyboard. Also, I couldn't get X to load properly until i dug around in .xinitrc and found that it was unable to make it's temp file in /tmp, which seems odd to me because it succeeds a few lines later making one for ssh-agent. Anyhow the obvious fix was just to point the mktemp line to /home/dsl/ as i knew that was writable, and everything came up fine. the post-install for gtk2-small worked fine as well, without a hitch. mikshaw, i wanted to test your version too, i was given a 403 Permission Denied when trying to wget it. Would be happy to try again, im in irc 24/7
I think the xfce.dsl is an awesome contribution and the idea of a post-install script as well...glad to help further DSL, if all i can contribute atm is testing, glad to do that!
Posted by undertow on Sep. 05 2005,00:29
i filled out my application and took the beta-tester job. yyyc514's four dsls are semi-functional together, although skippy locks up X and keyboard. Also, I couldn't get X to load properly until i dug around in .xinitrc and found that it was unable to make it's temp file in /tmp, which seems odd to me because it succeeds a few lines later making one for ssh-agent. Anyhow the obvious fix was just to point the mktemp line to /home/dsl/ as i knew that was writable, and everything came up fine. the post-install for gtk2-small worked fine as well, without a hitch. mikshaw, i wanted to test your version too, i was given a 403 Permission Denied when trying to wget it. Would be happy to try again, im in irc 24/7 :)
I think the xfce.dsl is an awesome contribution and the idea of a post-install script as well...glad to help further DSL, if all i can contribute atm is testing, glad to do that! :)
Posted by mikshaw on Sep. 05 2005,00:38
| Quote |
| My solution was all of like 6 lines and 1 new file |
I posted before seeing your last post...that response was to your first reply.
| Quote |
| mydsl-install is _not_ called during bootup as far as I can determine from source |
It is if you are auto-loading myDSL packages. dsl-config calls mydsl-load if there are myDSL apps in the root, or if you specify a "mydsl=" boot option, which in turn calls mydsl-install. If you are not auto-loading myDSL apps, there's no reason to run the post-install.
| Quote |
| What I offer is far from a "rewrite" of myDSL |
I see that now that I look at the script. As i said before, i was responding to what you had posted earlier, and it sounded to me like a lot of extra work just to run one more script.
| Quote |
| sometimes a script can still fail... unless it's a pristine CD one can't guarantee what environment it's going into |
I agree. I don't have much development experience beyond making a few myDSL packages, so I really don't know what it would take to make things bug-free.
| Quote |
| did you like the idea of making them unexecutable when finished rather than deleting? |
I don't really have a preference...I just thought maybe the idea could be expanded or modified in the future. The script i made overwrites the tmp file with each new package anyway, so i guess it doesn't matter at this point.
| Quote |
| It's main purpose is for dealing with .dsl packages that are subsequentially installed... so mkwritable is going to get called soon enough anyways |
Not necessarily. As I said i don't use many .dsl extensions, and when I do it's infrequently...just occasionally boot into XFree for a game or with some dev tools. Usually I use only tar.gz or uci extensions. It's not a huge difference in memory usage, but I figure why bother setting it up to run mkwriteable when there is no need? The files in your extension can be written to the system without running mkwriteable.../etc isn't in ramdisk, but it does allow a limited amount of writing.
It looks like your script is basically the same as mine, except 1) it runs at boottime regardless of whether or not it's needed, and 2) it runs all files found in the mydsl.postinstall directory. Keep in mind that you may be running unnecessary commands with both differences. The boot without myDSL apps that i mentioned is one. The other is the fact that mydsl-install is run with each myDSL application...you run all post-install scripts every time a myDSL package is installed.
Posted by undertow on Sep. 05 2005,00:49
i filled out my application and took the beta-tester job. yyyc514's four dsls are semi-functional together, although skippy locks up X and keyboard. Also, I couldn't get X to load properly until i dug around in .xinitrc and found that it was unable to make it's temp file in /tmp, which seems odd to me because it succeeds a few lines later making one for ssh-agent. Anyhow the obvious fix was just to point the mktemp line to /home/dsl/ as i knew that was writable, and everything came up fine. the post-install for gtk2-small worked fine as well, without a hitch. mikshaw, i wanted to test your version too, i was given a 403 Permission Denied when trying to wget it. Would be happy to try again, im in irc 24/7 :)
I think the xfce.dsl is an awesome contribution and the idea of a post-install script as well...glad to help further DSL, if all i can contribute atm is testing, glad to do that! :)
Posted by yyyc514 on Sep. 05 2005,03:14
| Quote |
| It is if you are auto-loading myDSL packages. dsl-config calls mydsl-load if there are myDSL apps in the root, or if you specify a "mydsl=" boot option, which in turn calls mydsl-install. If you are not auto-loading myDSL apps, there's no reason to run the post-install. |
Check again, it's only called in optional/* loops... the main auto-load loops do the loading manually...
| Quote |
| The script i made overwrites the tmp file with each new package anyway, so i guess it doesn't matter at this point. |
I leave them around... they delete themselves on a successful execution.
| Quote |
| It's not a huge difference in memory usage, but I figure why bother setting it up to run mkwriteable when there is no need? The files in your extension can be written to the system without running mkwriteable.../etc isn't in ramdisk, but it does allow a limited amount of writing. |
If possible I'll change this.
| Quote |
| It looks like your script is basically the same as mine, except 1) it runs at boottime regardless of whether or not it's needed, and 2) it runs all files found in the mydsl.postinstall directory. Keep in mind that you may be running unnecessary commands with both differences. |
Check /etc/init.d/dsl-config again, I might still be wrong but I'm pretty sure it has to be handled the way I've approached it.
| Quote |
| The other is the fact that mydsl-install is run with each myDSL application...you run all post-install scripts every time a myDSL package is installed. |
Upon success the scripts remove themselves... otherwise they stick around until the errors are dealt with, of course popping up during subsequent installs (kinda like how debian handles errors in the middle of installs).
I'm not sold on this last behavor, but failling scripts should be few and far between and serious enough to warrant attention when they do not work.
Posted by mikshaw on Sep. 05 2005,03:23
As I said in irc, I was wrong that mydsl-load is run during boottime. It was an assumption rather than a fact. I'm not sure why it was built like this, unless maybe it has something to do with xtdesk.
Posted by yyyc514 on Sep. 05 2005,16:48
I was just clarifying for non-IRCers... any other thoughts from anyone on this project?I haven't tested auto-install at bootup yet... might be a few bugs there, but for normal installs it works great... if it's going to be adopted I'd probably need to write a how-to for post-install authors...
Posted by mikshaw on Sep. 05 2005,20:04
And that also means that my whole approach to it needs to be re-thunk (as you were probably aware the whole time 
).The current DSL init process seems to allow custom activity only once the mydsl apps have been loaded, so it's either go with your idea of running all post-install scripts after dsl-config has run (i still need to get my head around the most efficient way to do this), or perhaps look more closely into the knoppix-autoconfig file since it runs before dsl-config. knoppix-autoconfig checks for a boot option to load a custom knoppix.sh, but i haven't done anything with it yet.
lines 77-86, 864-927
Posted by cbagger01 on Sep. 05 2005,20:08
I've done it with KNOPPIX.Just make sure to place your knoppix.sh script inside the KNOPPIX directory instead of at the root of the CDROM.
Posted by mikshaw on Sep. 05 2005,20:27
so that would find the script automatically rather than having to specify "myconfig=/dev/something" ? I see a number of possible ways to find it, and one seems to look in /cdrom/KNOPPIX, so I guess that would be it =).Gonna do some more playing in a short while and hopefully have some results to post tonight.
Posted by mikshaw on Sep. 05 2005,23:41
Found something that works for init and after login. I swear you never stop learning new things when you use Linux =o)
I spent at least an hour tweaking knoppix.sh, rebooting, retweaking, rerebooting...just couldn't get it to work during init. It seems that adding things to rcS.d does nothing. Maybe these files are loaded into ram together, before they run? Anyway, by adding to rc5.d instead, it works =o)
This is knoppix.sh:
| Code Sample |
| PISCRIPT=/etc/init.d/mydsl-postinstall rm -f /etc/init.d/mydsl-install cp /KNOPPIX/etc/init.d/mydsl-install /etc/init.d/ echo "$PISCRIPT" >> /etc/init.d/mydsl-install cat << EOF > $PISCRIPT #!/bin/sh for PIscript in /tmp/mydsl.postinstall/*; do [ -x "\$PIscript" ] && \$PIscript && chmod -x \$PIscript done EOF chmod +x $PISCRIPT ln -s $PISCRIPT /etc/rc5.d/S00mydsl-postinstall |
To use this feature, the post-install script for your myDSL package would need to be a uniquely named executable file placed in /tmp/mydsl.postinstall/
Keep in mind that since the script is run by root, any new files created by the script in /home/dsl will need to be chowned.
btw, this one should also work for uci extensions although i haven't tested it.
Posted by yyyc514 on Sep. 06 2005,00:20
To be complete you'd also need to add it to runlevel 2... incase someone is booting to console.How is this all that different from my post_install.dsl (now .tar.gz - need to upload) that simpy extracts the proper files already in place?
The one advantage I see is that you seem to simply append to mydsl-install instead of replace it... making this aspect of your approach possibly more cross-version compatible... perhaps not... depends on how much/little DSL has changed over time...
Of course my end goal is to see this included in the distribution, so exactly how we "add" the feature now will hopefully become of 0 importance in the future. Though I suppose for legacy CDs it might still be of import.
I think having a normally packaged .dsl or .tar.gz you just drop into place is the easiest approach to this sticky problem. If i were to adopt your "append" approach the initial post_install package would simply contain a post-install script of it's own to append the line to the right file... and that script would be run by the Sxxpost-install task in either runlevel 2 or 5... (I love how simple this stuff is when you really get into it)
Are we both really saying the same thing now, or not really? I'm not sure, enlighten me.
Posted by mikshaw on Sep. 06 2005,00:34
I don't think there is any difference, particularly since you have now made it tar.gz, except for the time when the files are copied...yours is an extension, mine is done before myDSL extensions are loaded. The end result seems to be the same.Mainly, I learn better with a hands-on approach, so regardless of whether or not our scripts accomplish the same task, i feel happy knowing i've learned something new...particularly the fact that the knoppix.sh works as easily as it does. I had doubts that it was carried over to DSL because when i first tried to do something with it months ago i couldn't figure out what i was doing wrong. This may open doors for future mods.
Posted by yyyc514 on Sep. 06 2005,01:11
I learn by doing too, but mostly this was an excersize to see how much could be done in how few lines of BASH. :-)Plus I really wanted my packages to be able to do post-installs...
Posted by cbagger01 on Sep. 06 2005,02:40
Yes, it will find the knoppix.sh script if it is located inside /cdrom/KNOPPIX directory even if you do not type in the "myconfig=xxx" cheatcode.I have not tried it with DSL, because DSL's myDSL functionality was already good enough for my purposes.