Question

I’m trying to run a bash script when my EC2 instances start up. All I want to do is start up GlassFish when the server starts. The command I’m trying to run is:

sudo /glassfish3/bin/asadmin start-domain

Which works when I enter it manually.

I have tried adding this command in a couple places with no luck:

• at the end of /etc/rc.local
• at the end of /etc/rc.d/rc.local
• created my own script in /etc/init.d/

I have given every script 777 permissions.

Anyone have any ideas on what I’m doing wrong?

Answer 1

Unless oddly configured, sudo wants authentication when run. It is normally meant to be run interactively.

Assuming that the script /glassfish3/bin/asadmin is owned by root, you can set its file permissions to 6755. This does what you probably meant sudo to do. Of course, it can also be dangerous and may be a security risk.

(@jcomeau_ictx is right, incidentally. You should check logs as he suggests.)

Update for the benefit of archival: The above answer fortunately seems to have solved the OP’s immediate problem, so we’ll leave it at that. However, since this answer will remain archived and others may look it up later, I should add more to it.

One can change the file permissions of any executable to 6755, but such is not always a good practice. The effect of such permissions is (a) to let anyone run the executable with (b) the full privileges of the executable’s owner. Sometimes, this is exactly what you want, but see: in the OP’s case, /glassfish3/bin/asadmin with such permissions can now be called by anybody, with any arguments, with full root privileges. If that is not what you want, then you must take some additional care.

Several ways of taking additional care are possible. One is as follows.

1. Leave the executable with file permissions 755.
2. Write and compile a small wrapper, a program which uses execv() of unistd.h to launch the executable.
3. If practicable, do not let the wrapper take any arguments; otherwise, let its arguments be as restricted and inflexible as they can be. Let the wrapper strictly control the arguments passed to the executable.
4. Let the wrapper be owned by root, but use chown to assign it a suitable group whose membership includes no users. You may prefer to start a new group for this purpose but, if you scan the /etc/group file on your system, you are not unlikely to find an already existing group that suits. For reference, you can list commands already belonging to special-purpose groups on your system by ls -l /bin /usr/bin | grep -vE '^([^[:space:]]+[[:space:]]+){2}(root[[:space:]]+){2}' or the like.
5. Give the wrapper file permissions 6754, thus making it nonexecutable except to the group in question.
6. Admit the calling script to the group, and give the calling script file permissions 2755.

If the calling script already belongs to a group, you can probably just use the same group throughout.

Several variations of the technique are possible, and it is unlikely that you will use exactly the one listed above, but if you read the manpage and/or info entry on the chown command and learn the details of file permissions, and if you experiment a little, you should be able to craft a solution that works for you without posing a security risk.