Re: How to execute script as root, and then an another script on behalf of an ordinary user
Re: How to execute script as root, and then an another script on behalf of an ordinary user
- Subject: Re: How to execute script as root, and then an another script on behalf of an ordinary user
- From: Xochitl Lunde <email@hidden>
- Date: Thu, 6 Jan 2011 10:51:56 -0600
>
> >> Yes, there are lots. As a simple example: why are you assuming
> that there is only one person logged in, or that there is even one
> person logged in to the computer. Both cases are valid.
> >
> > I guess i will have to ps -x | grep loginwindow and execute
> "launchctl bsexec" for every instance of loginwindow? if
there's no
> users logged
> > in, the loop will never be executed. Otherwise, it'll execute
for
> every user who's logged in (well, just like in that example on that
link).
> >
> >> We don't know exactly what you are trying to do, backing
out a
> step or two might be a really good idea. There are a lot of people
> on this list that can probably better help you out if you give them
> the information they need to help you.
> >
> > It's an NKE Kext , which is autoloaded by a "starter"-daemon
and
> whose status is displayed by an agent in a status bar. After
> installing, i want these daemon and agent to be launched
> immediately, without reboot.
>
>
> I understand the convince and elegance that you are going
for,
> but it might not be worth it. I am a bit prejudiced in this area as
> I worked on InstaDMG for a long time, but you should be aware that
> there are cases where the volume that your package is being
> installed to is not the root volume, so loading Kexts automatically
> should only be done with great care (a similar argument for the toolbar).
>
> And there are just so many variables in this area that
I am not
> sure that it is really worth doing. While it is brutal, and we
> should aim for better, I am with Greg on this one and I think that
a
> reboot is the best option.
>
> --
> Karl Kuehn
> email@hidden
>
I agree that this is really the best. While
I was *able* to get my daemons and agents to launch reliably, it took me
several tries to get scripts correct enough that it would work for command
line, ARD, and GUI installation for a local system volume only. Rebooting
in testing will also help you find problems your daemon might have after
installation. For example, StartupItems would let you create dependencies,
but launchd doesn't do that. So if you have a dependency on network
being available, you might find your daemon needs to be able to determine
if the network is available before doing other things. (A problem I still
need to solve part of, *sigh*)
Karl, do you have any tips on setting up the dev machines
for this sort of package? By this I mean, if my package rebooted
my computer every time I tested it, it would increase my downtime for testing
script changes. I run the scripts individually as much as I can before
running them as part of a package, but that is about it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden