Tag Info

Hot answers tagged

31

You want to remove the passphrase from a key file. Run this: openssl rsa -in key.pem -out newkey.pem Be aware that this means that anyone with physical access to the server can copy (and thereby abuse) the key.


17

There are a couple ways. If you just want to do this temporarily, you can remove the execute bit from the file: $ chmod -x /etc/init.d/varnish Then re-add it when appropriate: $ chmod +x /etc/init.d/varnish The "official" way in Ubuntu (as well as in Debian and other Debian derivatives), though, is to use the update-rc.d command: $ update-rc.d varnish ...


15

I've been guilty of removing the passphrase from my own key files in the past, because it's the simplest solution, but security-wise, it's not the best idea. An alternative is to feed the passphrase to Apache. You can do this with the SSLPassPhraseDialog option in your httpd.conf (or another file that it includes). If you only have one SSL site on your ...


12

Use chkconfig: chkconfig --level 345 mysqld on


9

I don't see a problem with it, if you know, for sure, that the Python interpreter will be available when the init.d script is being run. This, to me, indicates that you're looking at something being done relatively late in a multi-user (or "graphic console") run-level. However... This means that a specific version of the Python interpreter MAY be vital for ...


9

The best way to go for it are the daemontools. They allow you to monitor and respawn processes. See the documentation on their website: http://cr.yp.to/daemontools.html


9

supervise is a lightweight, efficient alternative. Under debian it is packaged in daemontools. You can also read this related question, which lists some supervise criticisms, and mentions restartd as another possibility. Finally, if you want something incredibly easy to setup, I've had great success with monit. It is also packaged in Debian.


9

So set it up to start at boot: chkconfig php-fpm on


9

Yes. There are issues of availability, speed, reliability, maintainability, etc, but init scripts can be written in whatever you want. As is implied in your question, the /usr filesystem must be mounted before you can use the interpreters residing on it. There are Perl modules for just this task. One example is Daemon::Control, there are many more for ...


9

First of all, init scripts are supposed to be run sudo /etc/init.d/name when you are not logged in as root( when logged-in user is sudo enabled) Secondly, when you run sudo /etc/init.d/nginx start ==> it fires the master nginx process as root and worker processes as the user you specified in your nginx.conf user directive(eg. www-data) Can you confirm ...


8

I'd say #2, but very close to #1 -- "Bad. Bad. Bad. Never do this." The standard, such as it is, for Linux init scripts is in the LSB, and while it never comes out and says "these are bourne shell scripts", several assumptions are made. One, that lines beginning with # are comments, happens to work out fine. More problematic is the requirement that the init ...


7

xbindkeys needs a running X server to work which isn't available at that stage of starting your system. You should add xbindkeys to your .xinitrc (see man page xinit(1)) or .Xsession (see man page Xsession(5)) instead.


7

You can just su. You won't need the password because the script will initally be running as root. There's also the runuser command. If you use /etc/init.d/functions you can use the daemon function which has an option for specifying the user to run as. I'd personally sway towards the latter all other things being equal.


7

Putting a file readable only by root somewhere into /etc is a technique I've come across a few times at least in Debian (dbconfig-common does that, for example). Sourcing a file with plain passwords belonging to root sounds like quite a good idea to me, given the fact that init runs as root and there's already a lot of sensitive files in /etc anyway ...


7

I agree that your solution seems a bit complex, so I'll go with "give me some idea how this could be implemented in an entirely different way" :-) The standard solution for this is to use a configuration management system, such as puppet, and allow users to add their stuff to the puppet config for the server. Puppet will then push out the start script and ...


6

iniscripts can do whatever they want. Of course it makes sense not to introduce new dependencies, just for the initscripts. grep however is fine on pretty much any system that's posix/susv3 compatible (linux, bsd, solaris, other derivatives). For more utilities that should always be there, see ...


6

Depending on your Linux distro and release, ultimately sysvinit scripts (those scripts in /etc/init.d/) are generally run from the symlinks which exist in /etc/rc[0-6S].d, by /etc/init.d/rc. Under Ubuntu, you're either using old-style sysvinit, or more recently, upstart. Under the upstart management directory (/etc/events.d/) you'll find a legacy mode that ...


6

See the man page for update-rc.d. To stop a service from running at boot: update-rc.d -f servicename remove Or: update-rc.d servicename stop 20 2 3 4 5 . If you have Debian squeeze or later, or Ubuntu 12.10 or later: update-rc.d servicename disable To allow a service to run at boot: update-rc.d servicename defaults If you have Debian squeeze ...


6

The settings in /etc/security/limits.conf usually get applied by the pam_limits PAM module. Services started by init don't run under a PAM session however, and so these settings are not applied. The only reliable way I've found to set this is to run ulimit from the initscript itself. Edit the ElasticSearch initscript and add something like this near the top: ...


6

If you run the script at boot time, when no one is logged in, how could it modify anything in the user's session? :-) You should run it from your .bash_profile startup script (or from /etc/profile, to run it for every user in the system).


6

Passing 1 on the kernel line in the bootloader should start it in single user mode, which should not start the initscript unless it is severely broken. If booting into single mode does not work then you will need to get the install disc and boot into rescue mode using it.


6

As Ignacio suggested, the simplest solution is to boot into single user mode. To do this press any key on the countdown splash screen before it boots into the kernel. From here highlight the proper kernel and press e. Press e again to edit the cmdline and at the end at either S, s, single, or 1. Press return and then b to boot. This won't run your init ...


6

Correct stop: start-stop-daemon --stop --oknodo --pidfile $PIDFILE


6

Write a wrapper script that calls your script and redirects the output to a files #!/bin/bash /path/to/your/script &>/path/to/logfile


5

1.: No - they go to STDOUT (if you use echo) or STDERR (if you use echo >&2). 2.: Your scripts have to write to logs and/or syslog on their own (your distribution might contain some init.d-functions that might help there - add your Distribution to your question). If you go for logs look for the tee command. If you go for syslog look at logger. You ...


5

You could make a function to echo the message to both the screen and to syslog, something like this: LOGGER="/usr/bin/logger -t $myScript" # check the location of logger for your system myEcho () { echo "$1" $LOGGER "$1" } You could also put that into a separate file and include it into your scripts with #!/bin/bash myScript=$(basename $0) [ ...


5

Check out /etc/init.d/skeleton for an example. This should be present on an Ubuntu host.


5

These days init is actually being replaced by upstart in Ubuntu server. So what you probably want to do if you are writing these scripts is to try to write upstart ones instead of init. Here is a Getting Started Guide for upstart in Ubuntu.


5

You can start the service manually by using sudo start avahi-daemon and not using sudo avahi-daemon start If you want it so the service starts at boot. You need to have a look at adding a symlink to /etc/rc2.d/ to point at /etc/init.d/avahi-daemon. It is probably easier to read up on the programs sysv-rc-conf or update-rc.d For mounting a disk you ...


5

If avahi-daemon is in /etc/init.d and you want to have it started at each boot, just add it to the startup scripts with: sudo update-rc.d avahi-daemon defaults But i'm surprised that avahi-daemon is not still linked in the required runlevels as it was probably added by the system. To have your disk mounted at boot, add a line in your fstab like suggested ...



Only top voted, non community-wiki answers of a minimum length are eligible