Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I finished installation of supervisord on my centos6, it works also well. But I found I could use command "kill" to kill supervisord itself. I think this is wrong, I suppose supervisord is not killable, otherwise it can not guarantee the safe of other services which controlled by it. So how can I make supervisord is not killable please.
This is by no means possible to be done in a correct way lets say, though there is something that you could try and i think it will work. In theory only root can kill all proccesses and all other can always be killed by their owner. What you could actually try is to create a user that has an unbreakable password and get root to start a procceess using su. (root won't be asked to provide a password but 'su' will change to that user)
su newacct ksh -c "/home/newacct/bin/the_process_to_start.ksh and its parameters"
su - newacct ksh -c "/home/newacct/bin/the_process_to_start.ksh and its parameters"
The dash says that you should execute the .profile of that user. It depends if you want to or not. (You don't have to execute a script, but I assumed you were likely to in this example.)
This way, nobody but root can kill this process because nobody can become that user.
You might want to google how to make an undecryptable password in /etc/shadow. It's easy actually.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Is it a bad idea to give a user sudo access to perl (or any programming language interpreter for that matter)
E.g., it lets the user do this:
sudo perl -e 'print `cat /etc/sudoers`'
when they can't just do a
cat /etc/sudoers
Or is there something I'm missing which can prevent this? (I'm assuming not...)
If you give sudo access to any interpreter (all programming languages and all shells) then that user can do anything he wants on the system. So yes, it is a very bad idea.
Similar bad ideas include giving sudo access to rm, mv, tee or any archiving program (like tar or zip).
This question is also not about programming but about system management and therefore better suited to e.g. SuperUser.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
No, it is not a duplicate of that, because I want to assign one directory to one (or more) user, when they log in throught SSH.
For example, according to user's loggin :
userFoo => I want him to arrive /somewhere/here/ after SSH login
userBar => I want him to arrive /somewhere/here/ after SSH login
userOof => I want him to arrive /anywhere/ after SSH login
And so on.
How can I do that ?
(They are connection with PuTTY and I can't force them to connect with additionnal data like ssh -t user#server 'cd /home/some/dir ; exec "$SHELL"'
Change the home directories of your users, as that's the place where they land after connecting.
The second to last entry in /etc/passwd holds this information, and can be edited for example from
userFoo:x:1000:1000:,,,:/home/userFoo:/bin/bash
to
userFoo:x:1000:1000:,,,:/somewhere/here:/bin/bash
When you log in a remote machine via SSH, it starts a shell, in most cases it's bash. It has a script, which executes every time it starts, can be found at ~/.bashrc. You may edit them, append a cd /somewhere to them.
Anyway, it's probably not a good idea, it's better to link appropiate folders to the users:
ln -s /somewhere/here ~/userFoo/comehere
ln -s /somewhere/here ~/user/comehere
ln -s /anywhere ~/userOof/comehere
So, you may just tell the users "please perform a cd comehere after you log in", it will drop them to the specified folders.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have a (little?) problem on my Debian.
When it boots, the X does not load automaticlly.
I need to log on the terminal (in any tty) and after run the command startx.
After run this command, everything works.
So, I think that I just need to configure anything to make the Debian run this command.
Debian has a script for that. To make X start on boot, execute (as root or with sudo):
update-rc.d xdm defaults
For more info, read it's manpage:
man update-rc.d
If you are using Gnome, you'll probably want to use gdm instead of xdm.
Ensure that your x-server is active in your current init level.
Have a look at your /etc/inittab for your default runlevel.
Further you should have something like
x:5:respawn:/usr/sbin/gdm -nodaemon
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
The root user on my CentOS 6 distro has a different shell prompt to other users that I create.
If I
echo $PS1
for root user, I get [\u#\h \W]\$
If I do the same for another user, I get \s-\v\$
If I run
which bash
I can see that both users are using the same shell (/bin/bash/).
Is the $PS1 variable being set differently for individual users or groups somehow?
Usually it sets a different PS1 for root in /etc/profile or /etc/bash.bashrc.
Run echo $SHELLto identify your shell (which bash tells you where Bash is, not whether you're using it).
To clearly tell if you at each and every command line whether you have super-user (root) privileges or not
Yes, it is set different (for users). The PS1 variable is read from the .bashrc of your home directory or /etc/profile or /etc/bash.bashrc.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
I need a shell scripting way to determine when a remote linux/OSX has completed all /etc/init.d/* for what ever run levels I have chosen to run in.
since I know I can ssh into a virutal box on my net while it is still booting and run commands like /bin/true or /bin/ps that not everthing is in the state it needs to be.
essentially I need to
while [ ${INIT_STILL_RUNNING_ON_REMOTE_SYSTEN} ]
do
sleep 30
done
ssh remoteUser#remoteSystem:command
You could put a script in the run-level you are interested in that is the last thing to run and first thing to shut down that touches a file somewhere to indicate it has run.
For instance, if you made a script called S99finished and put it in the run-level folder it would run last at that run-level. A corresponding K00finished would run first when shutting down.
S99finished could look something like:
#!/bin/bash
touch ~/.init_finished
and K00finished could look something like:
#!/bin/bash
if [ -e ~/.init_finished ]; then
rm ~/.init_finished
fi
Then your startup script would poll until ~/.init_finished existed at which point it would go on it's merry way.
Note, the startup scripts run as root, so using the home directory tilde will put it in root's home. That's probably not ideal for what you're doing, but illustrates the point. It's just as easy to put it in /var/log or somewhere else common to poll from. Just remember it has to have read permissions for everybody wherever you stick it.